Olá sejam bem-vindos ao canal engenharia de software com ênfase uml eu sou o professor Jenes Gets e eu já atuo na área de modelagem de software há vários anos eu tenho quatro víros publicados sobre o assunto e eu já ministrei diversas palestras e cursos técnicos sobre modelagem de software utilizando a linguagem uml na aula de hoje eu vou dar continuidade ao tema de verificação e validação dessa vez abordando as técnicas de leitura orientadas ao objeto Então vamos dar início a nossa aula então como eu falei hoje nós vamos falar sobre as técnicas de leitura orientadas
a objeto ou Object oriented Reading techniques ou oo RS essas esse esse é um conjunto de técnicas que foram propostas pela primeira vez pelo Guilherme horta Travassos um pesquisador brasileiro e na verdade elas são técnicas voltadas para a verificação de consistências principalmente consistências em modelos uml como nós vamos estudar então vamos dar início à aula então o uso da uml implica exige a a necessidade de verificar a corretude de cada modelo mrr individualmente e a consistência entre os diferentes modelos e entre os modelos e a especificação de requisitos Lembrando que a especificação de requisitos é
uma documentação que descreve ah os requisitos necessários ao software o objetivo das técnicas oort é procurar por inconsistência omissões ambiguidades e outras e outras anomalias mas principalmente procurar por inconsistências que possam prejudicar a qualidade do modelo ou dos modelos então a característica central das oorts é comparar informações entre Artefatos de especificação de requisitos e artefatos de projeto com objetivo de garantir a consistência a corretude e a completude Entre esses artefatos e também comparar diversos tipos de artefatos de projeto entre si para garantir que eles estão consistentes eles contêm as mesmas informações ah Lembrando que nós
temos eh artefatos produzidos durante a engenharia de requisitos como a especificação de requisitos e nós temos artefato fatos de projeto que determinam como o problema identificado durante a fase de engenharia de requisitos será solucionado bom na nas orts existem dois tipos de leitura as leituras verticais e as leituras horizontais a leitura vertical ela tenta determinar a consistência entre os modelos e a especificação de requisitos entre os modelos de projeto e especificação de requisitos Então ela procura verificar se o projeto sistema ele está consistente e correto em relação aos requisitos funcionais já a leitura horizontal ela
tenta garantir a corretude e consistência entre diagramas de projeto de diferentes tipos como diagramas de classe e diagramas de sequência Então esse tipo de leitura procura garantir que todos os artefatos de projeto Eles escrevem conceitos que estão consistentes entre si então vocês podem perceber que essa técnica de leitura é voltada principalmente para verificar modelos de projeto as técnicas que nós estávamos estudando antes eram voltadas para a verificação de ã documentos de especificação e requisitos embora essa técnica ela também Trabalhe com comparação de especificação de requisitos ela está mais concentrada em garantir que os modelos de
projeto os artefatos de projeto estão corretos e consistentes bom ã com relação às revisões verticais elas podem ser de dois tipos que são a comparação das iões de classe com a descrição de requisitos para garantir que o que está descrito nos requisitos se reflete conceitualmente nas classes seus atributos e métodos ã e ela também faz comparação entre os diagramas de interação principalmente diagram de sequência com casos de uso basicamente para determinar se o que um caso de uso específico descreve está consistente está refletido em um diagrama de sequência Ah já as revisões horizontais são comparações
de artefatos de projeto com outros Artefatos de projeto então nós podemos comparar diagramas de interação com diagramas de classe para determinar se ah os objetos descritos no diagrama de sequência por exemplo eles estão refletidos em classes num diagrama de classes no caso modelo do domínio Ah também são feitas comparações entre o diagrama entre diagramas de classe diagramas de máquinas de estatos e também entre diagramas de interação com diagramas de máquinas de estatos na aula de hoje nós vamos nos concentrar na nos nas três primeiras revisões nas duas revisões verticais e na primeira revisão horizontal que
se traduz na comparação dos diagramas de interação com o diagrama de classe Ah bom vamos estudar a primeira técnica então que é uma técnica vertical que compara o diagrama de classes com Ah o modelo de especificação de requisitos um artefato de especificação de requisitos Ah no caso se trata de uma comparação de um modelo de domínio um modelo de domínio é um diagrama de classes produzido durante a fase de projeto normalmente é uma evolução do modelo conceitual que é um diagrama de classe que já é produzido durante a fase de engenharia de requisitos e como
o nome diz ele demonstra os conceitos que são necessários ao software em termos de classes de entidade que são classes eh relacionados diretamente ao domínio do problema então se fosse no caso H um sistema de controle de pizzaria algumas classes de entidade ou seja classes que que representam entar os conceitos do sistema seriam pizza cliente pedido sabores tamanhos esse tipo de coisa então Eh lembrando ainda que Como já foi falado uma especificação de requisitos nada mais é que um documento que descreve Quais são os requisitos necessários ao software ele pode ser somente texto ou ser
complementado com outros artefatos como modelos de caso de uso ou modelos de classes conceituais bom mas eh no caso para essa técnica o diagrama de classes que nós vamos estar comparando com a especificação de requisitos é um modelo de domínio ou seja um um diagrama de classes produzido durante a fase de projeto que já trabalha a solução do problema identificado durante a engenharia de requisitos Portanto ele h as classes nele contidas já contêm métodos que fazem parte da solução é uma forma de descrever como solucionar o problema bom então o objetivo dessa técnica é Verificar
se os conceitos e serviços descritos pelos requisitos funcionais estão capturados apropriadamente pelo diagrama de classes Lembrando que um requisito funcional identifica um serviço uma função uma funcionalidade que o só software deve oferecer aos seus usuários bom Quais são as entradas para o processo desta técnica as entradas são um conjunto de requisitos funcionais como eu falei descrevem conceitos e serviços necessários ao sistema e um diagrama de classes no caso um modelo de domínio Que conterá classes com seus atributos e comportamentos o fato dele conter comportamentos já o caracteriza como um diagrama de classes de domínio porque
comportamentos eh são equivalent a métodos da uml e os métodos já fazem parte da solução do problema Lembrando que na engenharia de requisitos se identifica o problema mas não como resolvê-lo enquanto que no projeto já se trabalha na solução como resolver o problema bom ah então nessa técnica se examina cada requisito funcional em busca de substantivos substantivos podem ser classes ou atributos candidatos podem servir para identificar classes ou atributos candidatos eh que deve estar contidos no modelo domínio e também por verbos que representam o comportamentos candidatos ou seja métodos que podem estar representados no diagrama
de classe que podem ser representado o diagrama de classe Então se verifica o diagrama de classe para determinar se esses conceitos ou seja os substantivos e verbos foram capturados corretamente Lembrando que nem todo substantivo e nem todo verbo necessariamente corresponderá a uma classe um atributo ou um comportamento mas muitas vezes isso é verdadeiro ã então para cada substantivo identificado deve haver uma classe equivalente no diagrama de classes ou eventualmente esse substantivo esse conceito pode estar representado por meio de um atributo e para cada verbo identificado deve-se procurar um comportamento equivalente em uma classe o verbo
deve corresponder a um método e uma classe eventualmente pode acontecer desse comportamento estar dividido em um conjunto de comportamentos no diagrama de classe bom Aqui nós temos uma descrição simples de requisitos para o sistema de pizzaria online obviamente está incompleta apenas um trecho que nós vamos utilizar para ilustrar a aplicação da técnica bom então se trata da solicitação de pizzas por clientes então a descrição fala que os clientes devem poder poder solicitar pizzas via web eles podem escolher três tamanhos possíveis para cada pizza pequeno com quatro pedaços médio com seis pedaços e grande com oito
pedaços ao selecionar o tamanho da Pizza o sistema deve permitir que o cliente escolha tanto sabores quantos permitidos pelo tamanho da pizza pode ser um dois ou quatro ao terminar de escolher os sabores da Pizza deve ser possível ao cliente adicionar a pizza ao pedido o cliente pode adicionar quantas pizzas quiser o valor de cada pizza é calculado pelo preço do Sabor mais caro multiplicado pelo número de Pedaço da Pizza após escolher todas as pizzas desejadas o cliente poderá confirmar o pedido o que fará com que o pedido seja registrado Então esse é um pequeno
trecho da especificação de requisitos representado de forma totalmente textual apenas para ilustrar a aplicação da técnica bom nós vamos começar então identificando substantivos nessa nessa especificação então nós identificamos o substantivo cliente pizza tamanho pedaço sabor pedido valor e preço Lembrando que eh apenas para relembrar Claro substantivos são palavras que descrevem coisas que existem no mundo real bom então substantivos identificados como falei são cliente tamanho sabor valor pizza pedaço pedido e preço é importante ter cuidado com ã substantivos sinônimos certo às vezes é necessário agrupar sinônimos eh em torno de um termo único bom H então
ah Aqui nós temos um um modelo de domínio ou seja um diagrama de classe já relacionado à solução do problema produzido durante a fase de projeto relativo a ao sistema de pizzaria online Então você podem notar que existem diversas classes vamos Verificar se os substantivos encontrados na especificações de requisitos estão refletidos no diagrama de classes então o substantivo cliente ele tem uma classe cliente equivalente o mesmo acontece pro substantivo pizza está aqui pro substantivo tamanho que está aqui representada pela classe tamanho o substantivo pedaço que está representado aqui pelo atributo número de pedaços o substantivo
sabor que está representado pela classe sabor o substantivo pedido está representado pela classe faz pedido e o substantivo valor que está representado pelos atributos valor da Pizza valor do item Sabor e valor do Sabor Ahã mas o substantivo preço ele não foi encontrado nós temos o valor do Sabor nós temos o valor do ET sabor nós temos valor da Pizza Alguém poderia dizer pom preço e valor são são a mesma coisa seriam as sinônimos então exatamente o preço aqui se refere ao valor total do pedido então o valor total do pedido Ele vai ser a
soma de todas as pizzas que o pedido contém eh que por sua vez o valor de cada pizza é calculado pelo Considerando o tamanho da pizza e o valor do item de sabor mais caro ã então o atributo PR não existe que na verdade ele é um atributo calculado nós temos o método totalizar pedido cliente que calcula o valor do pedido somando o valor de todas as pizzas certo então não era realmente necessário um atributo preço até poderia ter o atributo preço do pedido mas talvez fosse um pouco considerado um pouco redundante uma vez que
esse valor pode ser obtido pela soma da do valor de todas as pizzas do pedido Ah é importante abrir um parênteses Ah para explicar porque que existe o a classe Sabor e a classe item sabor isso é necessário porque ao longo do tempo o valor de um sabor pode mudar então se eu quiser saber o valor de uma pizza ou mesmo o valor real de um pedido de algum tempo atrás antes que o os valores de alguns sabores tivessem sido modificados Então eu preciso guardar os objetos item sabor ou seja um sabor ele pode compor
vários itens Sabor e uma pizza pode conter vários itens sabor E um sabor ele se refere a um sabor específico e a uma pizza específica então para calcular o valor de uma pizza eu vou verificar todos os sabores que estão que são pertencentes a ela Lembrando que isso aqui é uma associação de agre de composição ou seja o a informação da Pizza Deve ser complementada pela informação dos seus itens sabores então no momento que se descobre o item sabor mais caro Esse vai ser o valor da Pizza multiplicado pelo total de pedaços que o tamanho
da Pizza escolhida possui bom Ah então por isso é necessário a classe item sabor para que eu guarde o valor de cada do que o cada sabor possuía na época em que a pizza foi pedida certo para manter a consistência para impedir que se o valor do Sabor mudar isso não perca o valor não não não altere o valor original de uma pizza ou de um pedido bom então Eh todos os substantivos foram identificados menos o substantivo preço mas que na verdade não não é necessário porque ele é um um um atributo um eh porque
ele pode ser calculado ã pelo método totalizar pedido não é necessário armazenar ah ok Aqui nós temos a identificação dos verbos na mesma especificação de requisitos então nós temos os verbos solicitar escolher selecionar adicionar calcular confirmar e registrar bom então como f lei são os verbos identificar solicitar escolher selecionar adicionar calcular confirmar e registrar bom ah solicitar na verdade corresponde ao próprio processo de solicitação de pizzas Então não é necessário eh um método solicitar escolher e selecionar são sinônimos Então nós vamos agrupar ele num termo único ah adicionar calcular confirmar e registrar são os outros
os verbos que foram identificados bom então vamos lá eh o verbo adicionar ele possui equivalente em adicionar pizza na classe no no método adicionar pizza na classe pizza Hã o método confirmar ele existe na classe pedido está aqui o método confirmar pedido e o e o verbo registrar existe possui equivalente registrar pedido na classe pedido Ah no caso ã o verbo selecionar ele está representado pelos métodos consultar número de pedaços consultar quantidade de sabores eh da classe tamanho Mas não tem um método explícito para selecionar certo se consulta um tamanho Ah mas não tem o
método selecionar explicitamente e não existe o método calcular não com esse nome mas na verdade existe o método totalizar pedidos cliente então esse método ele é o equivalente ao método calculado talvez deveria ser o talvez o nome deveria ser calcular pedido cliente você colocou o nome totalizar mas é o equivalente a calcular bom ã somente o o verbo selecionar é que não tem um equivalente ã assim direto certo o que eu tenho é vários métodos para consultar o tamanho Mas para selecionar o tamanho à Não tá Talvez eu devesse mudar o nome para ã selecionar
quantidade de sabores por exemplo selecionar tamanho por exemplo mas o a palavra foi utilizada consultar o que não é exatamente um problema só ã não corresponde exatamente a palavra na descrição de requisitos mas ele está representado aqui bom agora nós vamos falar sobre a técnica e que compara diagrama de sequência com o caso de uso então o objetivo é verificar seos diagramas de sequência eles descrevem uma combinação apropriada de objetos e mensagens de tal forma que seja possível capturar funcionalidade descrita por cada caso de uso Então as entradas para o processo são um caso de
uso descrevendo uma funcionalidade que deve ser fornecida pelo sistema um ou mais diagrama de sequência que descreve os objetos ou seja timelines Ah porque no diagrama de sequência não se usa exatamente o termos objetos se usa o termo timelines que na verdade são objetos que existem durante um tempo em um processo um diagrama de sequência sempre descreve um processo então o diagrama de sequência descreve ã um conjunto de timelines e um conjunto de mensagens que são disparadas durante o processo uma outra entrada é um ou eventualmente até mais diagramas de classe que contém as descrições
da classe relacionados aos às timelines do diagrama de sequência então os passos São primeiro identificar a funcionalidade que é descrita por um caso de uso e os conceitos necessários para realizá-la Então deve ser ler o caso de uso para entender a funcionalidade que ele descreve e encontrar os substantivos contidos no caso de uso esses substantivos descrevem os conceitos da funcionalidade então Aqui nós temos o caso de uso and o requisito funcional de escolher pizza então ã os substantivos que nós podemos encontrar são cliente pizza que Surge mais de uma vez Ah nesse nesse caso de
uso tamanh sabores pedido bom ah o segundo passo é para cada substantivo deve-se procurar identificar os verbos que descrev ações aplicadas nos substantivos ou pelos substantivos também deve se procurar por restrições e condições que sejam necessárias para que o conjunto de ações seja executado Ou pelo menos parte deles Ah também deve se identificar outras informações que que devam ser enviadas ou recebidas para que as ações possam ser executadas então Aqui nós temos alguns verbos nós temos os verbos apresentar selecionar permitir escolher eh adicionar acrescentar e registrar bom então deve-se verificar se cada substantivo que foi
identificado no caso de uso ele está representado no diagrama de sequência Ah é importante lembrar que um caso de uso ele contém um conjunto de cenários relativos a um determinado requisito funcional ele deve conter no mínimo Ah um cenário principal que é basicamente o caminho feriz o caminho ideal mas ele pode também conter cenários a a alternativos ou cenários de exceção e ou cenários de de exceção ã um caso de uso ele também contém H outras informações como o nome do caso de uso o ator principal que é o o ator que mais utiliza o
software que utiliza a a funcionalidade diretamente um ator representa um conjunto de usuários que assumem um papel no sistema pode haver atores secundários ser opcional um resumo do caso de uso possíveis pré-condições possíveis pós condições aqui não existem eh pré e pós condições e Aqui nós temos o cenário principal identificando as ações do ator e as ações do sistema bom então ah continuando então deve-se verificar se cada substantivo que foi identificado no caso de uso ele está representado no diagrama de sequência se isso não for possível então isso pode significar que um conceito que foi
usado para descrever a funcionalidade não foi representado no diagrama de sequência bom ã se existirem um ou eventualmente mais substantivos não identificados o diagrama de sequência então foi identificado um substantivo H estranho deve-se verificar se esse conceito ele é realmente necessário para projeto e se ele representa o nível de detalhe que é realmente apropriado nesse momento bom substantivos encontrados no caso de uso foram cliente pizza sabor tamanho e pedido então ã no diagrama de sequência nós temos todos esses conceitos representados por ã lifelines ou seja objetos de classe entidade e por um ator então h
o substantivo cliente é representado pelo ator cliente um ator não necessariamente irá corresponder a uma classe neste caso sim Ahã bom o substantivo pizza ele está representado por uma lifeline denominada pizza ou uma lifeline pertencente à classe pizza o o substantivo sabor também é representado por uma classe por uma por um objeto da classe sabor o substantivo tamanho é representado por uma lifel da classe tamanho e o substantivo pedido Ele é representado por uma lifeline da classe pedido e ainda existe um uma outra lifeline quees o item sabor bom isto aqui obviamente é o diagrama
de sequência relativo ao processo de escolher pizza ele contém objetos e classe entidade como sabor tamanho pedido pizza item sabor objetos de classe divisão e objetos de classe controle uma vez que ã o sistema foi estruturado por meio de uma arquitetura mvc mas essa técnica ela se concentra em validar o objetos ou seja lifelines de classes de entidade classe de controle classe de visão embora também possuam métodos eh não é o objetivo desta técnica a técnica está está concentrada em classe de entidade mas ela poderia ser aplicada em classe de controle ou classe de visão
também perfeitamente apenas nesse exemplo nós estamos nos concentrando em classe de entidade eh de novo ainda o substantivo cliente e que foi identificado nesse diagrama de sequência por meio de um ator ah com o mesmo nome nesta situação cliente tem uma classe equivalente mas não é uma regra um ator não corresponde necessariamente a uma classe um ator representa um conjunto de usuários ã bom eu não vou eh me ater a descrever em profundidade esse diagrama de sequência porque não é o objetivo desse vídeo nós estamos vendo a técnica a o conjunto de técnicas oorts mas
vocês encontrarão outros vídeos sobre diagrama de sequência nesse canal se vocês tiverem interesse em se aprofundar ã sobre esse tema bom ã então foi encontrado substantivo estranho que corresponde ao item sabor Ele está aqui então a pergunta é seria necessário que esse conceito estivesse também definido na especificação de requisitos na verdade não não haveria necessidade o item sabor ele é necessário para o diagrama de sequência mas não é necessário eh detalhar tanto a especificação de requisitos para conter esse tipo de informação ã então continuando nessa técnica para cada um dos substantivos não identificados no diagrama
de sequência deve se examinar o diagrama de classe que é o modelo de domínio obviamente e verificar sua se o substantivo é um atributo se o substantivo não aparece como atributo de nenhuma classe Então pode ter sido encontrado uma missão e l e por consequência também uma inconsistência depois identifica os serviços no diagrama de sequência e compare-os com a descrição usada no caso de uso É possível entender a funcionalidade esperada somente lendo o diagrama de sequência outra pergunta os objetivos estão trocando mensagens na mesma ordem que está especificada no caso de uso e finalmente os
dados das mensagens dos diagramas de sequência foram corretamente descritos nos casos de uso bom deve-se garantir que os objetos ou seja as lifelines elas trocam mensagens da mesma ordem especificada senão deve-se verificar se isto é um defeito uma anomalia se existe alguma inconsistência entre o diagrama de sequência e o caso de uso deve-se garantir que as mensagens sejam disparadas nos objetos corretos e que os dados trocados estejam nas mensagens corretas então Eh Aqui nós temos uma série de verbos que são selecionar apresentar eh permitir eh adicionar acrescentar eh registrar bom e vamos ver e esses
Passos essas ações do ator e do sistema Elas têm seu correspondente no diagrama de sequência sim Lembrando que aqui nós temos dois cenários o cenário principal e o cenário alternativo um cenário alternativo É um cenário que pode ocorrer ou não mediante a satisfação de uma condição no caso é que seja o primeiro item do pedido para então Eh registrar o pedido antes de adicionar a pizza mas aqui nós executamos o cenário principal em separado do cenário alternativo porque o cenário alternativo pode ocorrer ou não Ah bom mas então vamos ver esse conjunto de Passos os
passos 1 2 3 4 5 6 e 7 eles estão descritos no diagrama de sequência então sim vamos lá o primeiro passo solicitar escolher pizza Ele está contido aqui nesse setor do dia de de sequência certo o segundo o segundo passo apresentar tamanho e Sabores disponíveis ah está aqui o segundo passo ele envolve em apresentar tamanhos e Sabores disponíveis então aqui vai se consultar todos os ã sabores disponíveis para ã para para aquele tipo de pizza todos os sabores disponíveis de pizzas ah os tamanhos do caso não é necessário consultar a classe tamanho diretamente Porque
como eles são fixos já se apresenta diretamente os sabores pequeno médio e grande Ah o terceiro passo que é escolher tamanho está descrito aqui então que é o selecionar tamanho da pizza e o o quarto passo é permitir a escoler de sabores de acordo com o tamanho selecionado e selecionar tantos sabores quantos desejados até o limite do tamanho escoro quinto passo bom então eles Ele está contido aqui o os passos quatro e cinco então o cliente ele escolhe sabores os sabores escolhidos são passados da Visão para controlador e se inicia um laço então para cada
sabor escolhido consulta o valor daquele e daquele sabor Ah o passo seis que é o adicionar pizza está contido aqui e antes de chegar o passo sete existe o passo relativo ao o passo um do cenário alternativo que H determina que se caso seja o primeiro item do pedido então deve se registrar o pedido depois que ser é feito esse teste aí então se adiciona a pizza a ao ao pedido juntamente com cada um dos itens sabores ã itens de sabor Associados à pizza então esse é o sétimo passo está aqui então aqui o sexto
passo é adicionar a pizza ao pedido o sétimo passo é acrescentar a pizza Escolhida ao pedido e nós temos aquele passo correspondente ao cenário alternativo que foi H posicionado antes do do acréscimo a pizza escolhida Porque é necessário fazer esse teste antes Ahã OK e agora nós vamos falar sobre o diagrama de a técnica que compara o diagrama de sequência com o diagrama de classes no caso é o modelo de domínio então o objetivo verificar se um diagrama de classes descreve as classes e suas associações de forma que os comportamentos especificados do diagrama de sequência
estejam representados corretamente eh Então deve se verificar se as classes dos objetos ou seja timelines no diagrama de sequência estão contidas no diagrama de classes ou seja se para cada objeto no diagrama de sequência existe a classe correspondente àquele objeto também no diagrama de classe Ah deve-se também determinar se o diagrama de classe ele descreve os relacionamentos os comportamentos e condições que estão Associados à dinâmica dos serviços que estão descritos no diagrama de sequência Então as entradas para processo são diagrama de classe ã e diagrama de sequência que descrevem os objetos envolvidos nos processos bem
como de de que maneira eles colaboram para executar serviço do sistema então para cada diagrama de sequência identifica as classes de seus objetos de suas lifelines e identifica as informações trocadas entre os objetos deve-se considerar deve-se verificar se essas informações elas representam serviços e também caso a informação estiver muito detalhada então é necessário abstrair várias mensagens juntas ã de maneira a entender quais serviços estão sendo fornecidos então Aqui nós temos novamente o diagrama de sequência referente ao processo de escolher pizza então Ah nós temos várias lifelines referentes a objetos a a classe de entidade que
correspondem que eh devem corresponder a classe sabor a classe tamanho a classe pedido a classe pizza e a classe item sabor bom então dev deve se inspecionar o diagrama de classe o modelo de domínio para verificar se todo objeto contio no diagrama de sequência está representado por uma classe no diagrama de classes se um objeto uma lifeline não possui uma classe correspondente no diagrama de classes Então se identificou uma informação inconsistente entre os dois diagramas Isso precisa ser corrigido bom então asel que foram identificados no diagrama de sequência são sabor tamanho pizza e tem sabor
e pedido vamos ver se a essas lifelines elas possuem uma classe correspondente no diagrama de classes e sim vamos lá a classe A o a lifeline sabor possui o equivalente na forma da classe sabor a lifeline tamanho possui equivalente na forma da da classe tamanho a lifeline pizza possui equivalente na forma da classe pizza a lifeline item sabor possui equivalente na forma da classe item Sabor e a lifeline pedido possui equivalente na forma da classe pedido então está consistente até esse ponto bom agora deve-se verificar se para todo serviço todo comportamento identificar no diagrama de
sequência se existe um comportamento equivalente no diagrama de classe então é necessário então garantir é necessário verificar que a classe de todo objeto de entidade ou seja ah objetos de classe relacionados diretamente ao domínio do problema que recebe uma mensagem no diagrama de sequência se ela possui um comportamento associado no diagrama de classe então basicamente para toda ah mensagem que dispara um método em uma lifeline o diagrama de sequência este método deve estar também representado no diagrama de classe caso contrário a uma inconsistência então ah no diagrama de sequência nós nós identificamos comportamentos consultar descrição
sabor consultar quantidade de sabores consultar valor sabor registrar pedido adicionar pizza e adicionar item sabor vamos verificar se esses métodos esses comportamentos possuem equivalentes no diagrama de classe lembrando novamente que esse diagrama de classe é o modelo domínio ou seja ele já identifica a solução uma vez que as classes contém métodos Essa não é a única característica do modelo domínio Mas é uma das características que se destacam nesse nesse tipo de modelo então sim vamos ver aqui nós temos o método consultar descrição sabor vamos ver se existe essa esse método na classe sabor a classe
sabor está aqui nós temos o consultar descrição Sabor e e depois nós temos o o método consultar quantidade de sabores é disparado numa lifeline da classe tamanho então sim nós temos aqui o método consultar quantidade de sabores e nós temos aqui o método consultar valor sabor disparado num objeto da sabor objeto e lifeline são a mesma coisa a única a única diferença que uma lifeline é um objeto que existe durante um tempo mas ok vamos verificar se o método consultar valor sabor existe na classe sabor Existe Nós temos aqui o método consultar valor Sabor e
quanto ao método registrar pedido disparado num objeto da classe pedido vamos ver na classe pedido nós temos o método registrar pedido Está correto e nós temos o método adicionar pizza em uma lifeline da classe pizza e existe o método adicionar pizza está aqui e Finalmente nós temos o método adicionar item e Sabor disparado em uma lifeline da classe item sabor Aqui nós temos a classe item Sabor e nós temos o método adicionar item sabor então ã esse diagrama de sequência está consistente com este modelo domínio ah finalmente deve-se garantir que exista uma associação no diagrama
de classes entre classes correspondentes aos objetos ou seja as lifelines eh de classe entidade que trocam mensagem do diagrama de sequência caso isso não seja verdadeiro então uma associação está presente num diagrama de sequência mas não um diagrama de classe e isso caracteriza uma inconsistência bom ah a única mensagem que é trocar entre lifelines de classe entidade é a mensagem disparada da pela lifeline pizza em uma lifeline da classe item sabor as outras mensagens são disparadas entre ã classes de Fronteira no caso a visão escolher pizza e classe de controle no caso a controladora escolher
pizza Lembrando que nós estamos utilizando arquitetura mvc na arquitetura mvc nós temos módulos de visão módulos de controle e módulos de modelo então na nos modos de visão nós temos as classes de Fronteira ou as classes de visão que são as classes que interagem com os atores Ah o módulo de controle contém as classes controladoras que entre outras funções interpretam os eventos que ocorrem nas classe de fronteira e se acharem necessário Solicito a execução de métodos pelas classes pelos objetos das classes de entidade e o módulo de modelo contém justamente as classes de entidade que
são classes relacionadas diretamente ao domínio do problema certo eh então Eh como esse essas classes estão em módulos separados não pode haver associações entre elas mas aqui nós temos duas eh dois objetos duas lifelines de uma classe de entidade que troca mensagens vamos vamos ver se existe a correspondência de uma associação entre elas Ah então sim no meu modelo de domínio no meu diagrama de classes do sistema de pizzaria eu tenho uma classe pizza e uma classe item Sabor e elas estão associadas por meio de uma associação do tipo composição então o diagrama de sequência
e o diagrama de classes também estão consistentes nesse sentido e nós terminamos mais essa aula estudamos mais uma técnica de leitura o mais uma técnica de leitura no caso três técnicas da relacionadas ao conjunto de técnicas de leitura orientadas a projeto Ah eu espero que vocês tenham gostado dessa aula eu espero que essa aula tenha sido útil para vocês se vocês gostaram dessa aula eu peço que compartilhem com quem possa ter interesse curtam esse vídeo e se ainda não estão inscritos eu peço que se inscrevam no canal obrigado pela atenção nós nos vemos nas próximas
aulas
