Diagrama de Sequência - Parte IV - Exemplos

Olá sejam bem-vindos ao canal engenharia de software com ênfase ml Eu sou professor Denis gueres e eu já atou na área de modelagem de software há vários anos eu tenho quatro livros publicados sobre o assunto e eu já ministrei diversas palestras e cursos técnicos sobre modelagem de software utilizando a linguagem uml ah na aula de hoje eu pretendo finalizar o o tema sobre o diagrama de sequência na Nesta aula eu vou apresentar alguns exemplos práticos de modelagem de diagrama de sequência eh referentes a casos de usos primários do Sistema de Controle bancário que eu tenho

utilizado como estudo de caso ao longo das nossas aulas Então vamos iniciar a nossa aula então como eu falei essa é a quarta aula sobre de sequência e a última vamos apresentar alguns exemplos práticos Ah eu gosto sempre de fazer uma pequena propaganda como eu falei eu já publiquei quatro livros sobre o assunto o meu primeiro livro foi o mrr uma abordagem prática que na época tratava da omr 1.5 mas já abordava ao ml2 no final do livro depois eu lancei o ml2 guia de consulta rápida Poucos Anos depois eu lancei o m2 guia prático

e finalmente eu lancei o meu livro mais completo que é o dois uma abordagem prática que se encontra na terceira Edição Mas vamos ao conteúdo bom eu vou começar e enfocando o processo de abertura de conta comum mas nesse momento eu vou apresentar um diagrama de sequência como modelo preliminar ah normalmente os diagramas de sequência eles são produzidos durante a fase de projeto o que em geral Eles já enfocam a solução do problema porém alguns autores defendem que o diagrama de sequência ele já pode ser produzido durante a fase de engenharia de requisitos bom Mas

acontece que a engenharia de requisitos ela se preocupa em identificar o problema não a solução ela primeiro ela defende que durante a engenheria de requisitos deve-se compreender o que precisa ser feito para então pensar em como vai ser feito então nessa situação nessa fase se for utilizar o diagrama de sequência ah os diagramas de sequência produzidos eles devem ser tratados como caixas pretas ou seja eles não devem especificar como o processo vai se desenrolar internamente Isso significa que nós não vamos identificar os métodos eh disparados entre as lifelines das classes de entidade Lembrando que classe

de entidade são classes relacionadas diretamente ao domínio do problema elas contém a lógica do negócio Ah elas produzem muitos objetos e esses objetos muitas vezes serão persistentes ou seja precisarão ser gravados em disco então um diagrama de sequência produzido durante a fase de engenharia de requisitos ele identifica somente os atores que estão envolvidos naquele processo as classes Deão que são as classes que servem de intermédio entre os atores e o sistema e eventualmente as classes controladores mas não as classes de entidade aliás as lifelines referentes à classes entidade Aqui nós temos um exemplo de modelo

preliminar do diagrama de sequência do processo de abertura vocês percebem que nós temos uma Instância do ator cliente uma Instância do ator funcionário e agem durante esse processo uma Instância da classe visão abertura de conta e uma Instância da classe controle abertura de conta a classe divisão é uma classe bounder como demonstra o seu estereótipo Ou seja é uma classe de Fronteira uma classe que serve de intermédio entre os atores e o sistema e a classe controladora é uma classe do tipo controle como também demonstra o seu estereótipo is tem um estereótipo gráfico que modifica

o seu desenho padrão e interpreta os eventos que ocorrem na visão mas nós não temos classes de entidade por quê Porque n se nós envolvemos classe de entidade nós começaremos a trabalhar com a solução do problema que não é objetivo da fase de engenharia de quisitos então o processo começa com o cliente solicitando abertura de conta ao funcionário Lembrando que isto que esta seta ela representa um evento certo no caso o evento de solicitação de abertur de conta ah e o funcionário ele dispara um evento executa uma ação no na interface do sistema esse evento

se traduz na consulta ao cliente a visão Então ela Repassa esse evento paraa controladora transmitindo CPF a ser consultado e a controladora ela apresenta os dados do cliente mas de onde os dados do cliente foram retirados devia ter sido feita consulta a uma classe pessoa física a uma lifeline da classe pessoa física mas como pessoa física é uma classe de entidade ela não se encontra aqui então o processo para recuperar esses dados ele está escondido ele não é demonstrado porque isto é um modelo preliminar produzido durante a fase de engenharia de requisitos em seguida após

receber os dados do cliente o funcionário ele po Pode se achar necessário gerenciar o cadastro de clientes issoão C porque o cadastro do cliente pode estar desatualizado ou o cliente não ter cadastro no banco Então essa situação de C essa situação opcional é representado por um fragmento combinado do tipo opt Lembrando que fragmentos combinados Como já foi ensinado em aulas anteriores representam uma modelagem Independente de situações ã como teste sem então testes simples como no caso de fragmento combinado tipo opt laços eh operações atômicas tratamento de sessões paralelismo esse tipo de coisa no caso Então

esse opt representa uma situação possível mas não obrigatória de ter que ã atualizar o cadastro de clientes um fragmento combinado tipo tico Como já foi ensinado muitas vezes corresponde a uma associação do tipo extent no modelo de caso de uso bom se for necessário Então se faz referência ao processo de gerenciar clientes isto aqui como também já foi ensinado anteriormente representa um uso de interação ou ocorrência de interação dependendo da versão da uml quer dizer que eu devo procurar por um diagrama de mesmo nome que contém os passos eh sobre Como gerenciar o cadastro dos

clientes então o uso de referências a diagramas de sequência já modelados torna A modelagem mais simples e mais rápida e também facilita a manutenção bom depois de verificar se é necessário ou não cadastrar o cliente ou alterar o seu cadastro o cliente ele escolhe a senha da conta o funcionário solicita a abertura da conta visão a visão avisa com a controladora que foi feita uma visitação de abertura de conta e a controladora ela solicita que a visão emita o cartão da conta mas todo o processo para abrir a conta está escondido porque como eu já

falei antes isso é o modelo preliminar o processo de abertura de conta já faz parte da solução depois da conta ser aberta o cliente ele fornece o valor para depósito e o funcionário informa o valor da da para depósito fazendo referência ao processo de realizar depósito que é um outro processo que está modelado em um outro diagrama de sequência que só é referenciado nesse diagrama aqui um exemplo de modelo preliminar do diagrama de sequência produzido durante a fase de engenharia de requisitos alguns autores defendem que isso pode ser útil Em algumas situações eu pessoalmente defendo

que o diagrama de sequência deve ser produzido durante a fase de projeto Porque como já foi falado antes ele apresenta muitas vantagens para o projeto uma vez que detalha as mensagens que serão disparadas em um determinado processo e identifica quais os métodos vão ser disparados durante essas mensagens esses métodos eles permitem transformar o modelo conceitual que é um diagrama de classes produzido durante a fase de engenharia requisitos sem detalhar detalhes da solução como os métodos e transformar esse modelo conceitual em um modelo de domínio que é produzido durante a de projeto no modelo domínio eu

tenho detalhes de solução como os ditos métodos bom aqui eu tenho o diagrama de sequência do processo de abertura abertura de conta comum só que dessa vez representando o modelo detalhado é o mesmo processo só que dessa vez eu estou identificando classes de entidad e também os métodos disparados nessa nessas eh instâncias dessas classes de entidades eh então isso só pode ser produzido durante a fase de projeto e como eu falei à medida em que eu vou eh modelando diagramas de sequência eu consigo identificar quais os métodos necessários a cada processo e com isso eu

vou enriquecendo o meu modelo conceitual e transformando ele no modelo de domínio é claro que não basta só isso eu tenho que examinar o modelo de domínio e e possivelmente acrescentar mais detalhes referentes à solução bom mas aqui se acrescentou ao diagrama de sequência Abrir conta comum uma lifeline da classe pessoa física chamada pum e uma lifeline da classe contra comum chamada comum essas lifelines elas se referem à classe de entidade nesse momento não se aplicou o estereótipo entity a nenhuma delas porque eu quero manter a padronização com os primeiros exemplos que foram apresentados nos

primeiros exemplos ainda não se utilizava os estereótipos Tic ah nas classes entidad nos exemplos seguintes nós vamos aplicar os estereótipos então após receber o CPF a consultar a controladora solicita que a lifeline t Zom da classe entidade pessoa física dispare o método consultar CPF passando como parâmetro o CPF representado por este long aqui o texto consultar cliente dois pontos era meramente explicativo e opcional ah depois disso depois de executar o método consultar CPF a o objeto ele retorna os dados do cliente o tipo string aqui vale a pena um comentário que já havia sido feito

nas aulas anteriores na uml e principalmente no diagrama de sequência não se costumam representar métodos do tipo get e set exceto em determinadas situações por quê Porque os métodos Gets e sets eles podem ser em grande quantidade vai deixar as classes muito grandes e eles não acrescentam uma informação importante Gets e sets são quase que óbvios então eles não precisam ser declarados no diagrama de classes e eles também não costumam ser representar o diagrama de sequência exceto em determinadas situações situações que relativamente simples Agora eu preciso nessa situação retornar várias informações sobre a pessoa física

não vale a pena num diagrama de sequência pegar e criar um get pro nome um get pro endereço um get para cada um dos atributos da classe pessoa física isso vai deixar o diagrama de sequência muito extenso e não vai acrescentar grande informação Então se costuma utilizar um método mais genérico no caso eu chamei aqui o método consultar CPF e ele já representa todos os possíveis Gets necessários aqui retorna os dados do cliente bom Ahã agora vocês vão notar também que o meu fragmento combinado Tipo opt ele abrange também as linhas de vida da classe

PF Zom aliás da classe pessoa física da a lifeline p zoom da classe pessoa física uma vez que ela está envolvida diretamente no processo de gerenciar clientes ah depois que é feita a solicitação de abertura de conta a controladora ela dispara um método que eu chamei aqui de abrir conta que recebe com parâmetro a senha do objeto a ser criado então vocês notem que o objeto comum da classe conta comum passa a existir somente nesse momento somente Nessa altura do diagrama ISO significa que ele foi instanciado que ele foi criado nesse momento então ISO aqui

caracteriza o método Construtor alguém pode dizer assim não esa aí em Java o método Construtor tem que tem o mesmo nome da Class sim mas métodos construtores variam muito de linguagem para linguagem então Nós criamos o método Abrir conta ele é um método que vai abrir uma conta e nesse processo vai instanciar um objeto da classe como um Então na hora de implementação dependo da linguagem algumas pequenas adaptações precisariam de ser feitas Mas de qualquer forma isso aqui é um método Construtor que instanci um objeto da classe como um Aliás instanci o objeto como um

da classe conta comum então a a instanciação desse desse objeto retorna o número da conta do tipo long aí a controladora ela solicita a emissão do cartão da conta e o cliente ele vai fornecer um valor para depósito que vai ser informado pelo funcionário e vai invocar o processo de realizar depósito por meio de um uso de interação então este aqui é o processo de abertura de conta comum completo modelo detalhado ado produzido durante a a fase de projeto aqui então envolvendo classes de entidade inclusive eh ilustrando um exemplo de instanciação de criação de uma

um objeto da classe conta comum bom Aqui nós temos um outro exemplo que é o diagrama de sequência referente ao processo de realizar depósito então eu tenho novamente uma Instância da do ator cliente uma Instância do ator funcionário uma Instância o lifeline da classe divisão realizar depósito uma Instância da lifeline referente à classe controle realizar depósito e eu tenho uma lifeline da classe de entidade conta comum eu sei que conta comum é uma classe de entidade porque eu apliquei o estereótipo entity nesta lifeline o estereótipo entity é um estereótipo gráfico que modifica o desenho padrão

do deste componente então ao invés de como no exemplo anterior ele ser representado como um retângulo ele passa a ser representado como este símbolo este círculo com traço embaixo Este é o símbolo de classes ou objetos de classe de entidade então eu tenho aqui uma lifeline da classe conta comum um objeto de uma classe de entidade como já foi falado antes um objeto uma classe de entidade aliás uma classe de entidade se refere ao domínio do problema contém a lógica do negócio eh e vai conter muitos objetos e eles provavelmente deverão ser persistidos então durante

esse processo o cliente ele solicita e ele informa o número da conta ao funcionário Ah o funcionário ele consulta a conta para ver se ela existe ele faz isso por meio da visão a visão Repassa o evento pro pra controladora a controladora então solicita o disparo do método consultar conta em um objeto da classe conta comum passando como parâmetro o número da conta ah esse método retorna a cadeir significa que a conta existe então a controladora Avisa o funcionário por meio da visão e a conta é Vá então o cliente é autorizado a fornecer o

valor a depositar o funcionário Repassa o valor que deve ser depositado na visão a visão Repassa o valor a depositar para controladora e a controladora solicita o disparo do método depositar valor passando com parâmetro um long Double contendo o número da conta e o valor a ser depositado o método retorna verdadeiro significa que o depósito foi realizado com sucesso e a controladora Avisa ao funcionário por meio da Visão o depósito foi concluído em seguida fa referência ao processo de registrar movimento uma vez que é necessário registrar a operação de depósito naquela conta isso está definido

num outro diagrama então só faço referência a esse processo ele eu não preciso detalhar ele novamente eu simplesmente ah insiro essa essa referência sobre as linhas de vida dos objetos envolvidos Então isto aqui nesta situação eh quando não existe uma condição a ser atendida corresponde a uma associação de inclusão no modelo de caso de uso aqui nós temos um outro diagrama de sequência correspondente ao processo de emitir estrato então no processo de emitido Exato eu tenho uma Instância da do ator cliente uma lifeline referente à classe visão emitir extrato uma lifeline referente a classe de

controle de emtir de de emitir extrato e duas lifelines de classe de entidade conta comum e movimento todas essas classes já foram explicadas nas aulas sobre o diagrama de classes então o processo inicia com cliente informando o número da conta o número da conta é repassado pela visão PR controladora a controladora em resposta consulta conta o método retorna verdadeiro quer dizer que a cont existe a controladora então solicita a senha o o Cliente informa a senha a senha informada passada para controladora a controladora solicita aid a validação da senha para lifeline da classe conta comum

Ah o método retorna o método retorna O valor verdadeiro quer dizer que a sen tá valendo ela é Ela é válida a controladora informa que a sen é válida então o Cliente informa o período Inicial e final do trato ah os períodos informados são repassados para controladora a controladora então solicita a execução do método emitir extrato passando com parâmetro dois tipos ã date então ã a a lifeline da classe conta comum ela dispara o método consultar movimento em objetos da classe movimento eles vão retornar ah os valores referentes ao movimento dentro daquele período notem que

nós temos aqui um fragmento combinado tipo loop acompanhado pela condição de guarda para cada movimento do período Isso significa que enquanto houverem movimentos dentro do período informado vai se disparar esse método em objetos da classe movimento então isso aqui eu estou representando um laço por meio de um fragmento combinado a a classe conta comum então recebe o resultado dos movimentos retorna extrato para controladora e apresento o extrato na visão então Aqui nós temos mais um diagrama de sequência referente ao processo de emissão de extrato bom então esses são três exemplos de diagrama de sequência outros

exemplos do Sistema de Controle bancário foram apresentados H nas aulas sobre o diagrama de sequência anteriores e agora nós vamos apresentar diagrama de sequência eh referentes ao padrão aos padrões repository e d e também foram explicados nas aulas sobre o diagrama de classe os padrões repository Ideal São padrões de persistência embora o repository trabalha mais em memória mais não ele trabalha em memória mas ele é um auxiliar para o processo de persistência ele gerencia coleções de objetos em memória enquanto que o padrão da ele encapsula a lógica para a gravação de objetos em disco então

Aqui nós temos um diagrama de class um diagrama de classes referente à classes utilizadas pelo padrão da Ah então Aqui nós temos uma classe que eu chamei repositório conta substitui a classe bus Object já foi ensinada em outros vídeos a classe contal propriamente DIT que gerencia o processo de persistência de objetos de classes conta comum ou especial ou poupança essa classe ela encapsula a lógica para persistir informações na tabela conta comum persistir objetos na tabela conta comum e Ela utiliza uma uma uma classe temporária que eu chamei de conta transferência bom esse padrão Já Foi

explicado anteriormente no nas aulas sobre o diagrama de classe na aula 9 bom então Aqui nós temos um diagrama de se pensa referência ao processo de saque utilizamos os padrões reposit o processo de saque já havia sido explicado nas aulas anteriores Mas agora nós nós inserimos a lógica para eh persistência dos objetos persistência recuperação de objetos da classe conta comum bom esse diagrama ficou um pouco extenso então aqui eu vou fazer um recorte da parte de recuperação de objetos e gravação de objetos bom Ah vocês notem que o padrão é o o o processo se

inicia com a informação do número da conta para o cliente repasso paraa controladora só que diferente de ir direto Consultar a conta como era utilizado anteriormente Aqui nós temos a o o trecho referente à recuperação desse objeto bom vamos passar pro paraa lâmina seguinte que tem isto mais eh tem um recorte mais detalhado essa parte então Eh no momento em que um número da conta é informado a controladora solicita ao repositório da conta que retorne a conta consultada Lembrando que uma classe repository ela gerencia ela controla uma coleção de objetos e memória e memória RAM

então no caso a classe repositório conta ela contém uma coleção de objetos eh do tipo conta na verdade aqui é uma lifeline da classe repositório conta então ela representa um objeto dessa classe então a controladora ela solicita o retorno da conta mas nessa situação específica a a o repositório ela não contém essa conta na sua coleção Então ela tem que solicitar a sua recuperação do disco então ela vai criar um objeto da classe cont Dal aqui o método Construtor e ela vai selecionar a conta solicitada então a conta da por sua vez ela vai solicitar

a recuperação de dados da tabela conta comum os dados serão retornados à conta Dal e a conta Dal vai criar um objeto de transferência e foi chamado aqui conta transferência ele foi criado a partir desse momento ele vai retornar um objeto paraa conta Dal e a conta Dal vai retornar esse objeto para o repositório o repositório vai então criar um objeto da classe comum um objeto da Classic de entidade comum que vai ser trabalhado pelo processo de H saque então vai se vai se retornar verdadeiro o a controladora vai Consultar a conta vai se retornar

verdadeiro vai ser solicitada a senha a senha vai ser validada p um objeto da classe conta comum verdadeiro eh ele existe vai se informar o valor a sacar Ah vai ser disparado o método sacar valor no objeto da classe conta comum verdadeiro for possível sacar o valor vai ser liberado vai se registrar o movimento Ok mas nesse momento eu quero persistir essa atualização do objeto da classe conta comum então aqui é feito uma ação da conta no objeto da classe repository poderia ficar só nisso enquanto nós trabalhamos memória mas por algum motivo vamos supor que

o espaço disponível em memória já tá já tá muito grande então vai ser feita a persistência do repositório ou deste objeto específico em disco então nós temos esse outro trecho aqui então no momento que é feita a Sol Estação de autorização de conta eh o objeto transferência conta ele recebe esse parado método set saldo tá eh onde é atualizado o atributo saldo desse objeto depois é solicitado a é solicitada a atualização no objeto da classe da a classe da ela eh solicita os dados do objeto transferência e ela atualiza os dados na tabela eh conta

comum aqui neste caso específico nós estamos utilizando sets Gets e sets certo mas como eu falei anteriormente normalmente os diagram de sequência não se usa nessa situação específica foi necessário utilizar para exemplificar essa situação então Aqui nós temos um exemplo de como funciona o processo de persistência de objetos em memória e em disco por meio de classe repository e classes D e é isso nós terminamos a nossa aula de hoje finalizamos o tema sobre o diagrama de sequência eu espero que o conteúdo tenha sido útil se vocês gostaram dessa aula eu peço então que vocês

curtem compartilhem que ainda não são inscritos no canal se inscreva e eu agradeço a atenção de todos Obrigado Y