Diagrama de Pacotes - UML

[Música] Olá sejam bem-vindos ao canal engenh de software com ênfase uml eu sou professores gueres e eu já atuo na área de modelagem 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 na aula de hoje eu vou abordar o diagrama de pacotes esse diagrama ele permite organizar o sistema em termos de divisões lógicas ele pode ser utilizado para representar diversos sistemas integrados ou os diversos módulos que compõe o sistema Principalmente quando se escolhe uma arquitetura de software

específica para organizar os elementos do sistema como por exemplo a arquitetura mvc nós vamos ver exemplos disso ao longo da aula de hoje então vamos dar início ao nosso conteúdo então ah como sempre eu gosto de fazer uma pequena propaganda eu já publiquei quatro livros sobre o assunto meu primeiro livro foi o Mr uma abordagem prática que na época trabalhava com Mr 1.5 mas já abordava o MR2 no final do do livro eh depois eu lancei um livro exclusivo sobre o ml2 que foi o guia de consulta rápida Poucos Anos depois eu transformei esse guia

num livro mais completo que foi o m2 guia prático e finalmente eu lancei o meu livro mais completo que é o ml2 uma abordagem prática que se encontra na terceira Edição eu já estou trabalhando na quarta Edição e pretendo lançar essa nova edição ainda esse ano Mas vamos ao conteúdo então o diagrama de pacotes como eu falei ele representa os diversos as diversas divisões lógicas que um sistema está eh dividido está organizado ah essas divisões lógicas elas são chamadas pacotes e esse diagrama ele também permite demonstrar como esses pacotes estão possuindo dependências entre si Então

esse diagrama ele é bastante útil para representar a arquitetura do sistema ou seja como o sistema está organizado logicamente então o elemento mais básico do diagrama de pacotes é justamente o pacote então um pacote ele permite agrupar um conjunto de elementos e permite te dar um nome uma uma denominação para esse grupo então o pacote ele pode representar um sistema um subsistema um Framework uma biblioteca um módulo ou camada de uma arquitetura entre outras possibilidades e o pacote ele pode conter outros pacotes como como nós vamos ver ao longo dessa aula aqui nós temos um

exemplo de pacote um pacote representado como um retângulo contendo uma aba na sua parte superior que possui a denominação do pacote Então esse pacote aqui ele representa o Sistema de Controle bancário que nós temos modelado ao longo desses vídeos um pacote ele pode ter elementos internos normalmente ele trá elementos internos mas esses elementos eles podem ser detalhados Aqui nós temos eh um exemplo disso onde nós determinamos que o sistema de controle bancário possui h um conjunto de elementos que representam as classes de entidade que compõe esse sistema no caso as classes pessoa pessoa física pessoa

jurídica conta comum conta especial conta poupança e movimento Lembrando que classe identidade são classes relacionadas diretamente ao domínio do problema normalmente essas classes vão conter muitos objetos esses objetos precisarão ser persistidos E essas classes contém a lógica do negócio claro que para os que estão acompanhando eh esse canal há mais tempo em outros vídeos vocês vão lembrar que existem outros elementos do Sistema de Controle bancário como classe de visão e classe de controle nós vamos demonstrar Eh esses outros elementos mais adiante aqui é simplesmente para ilustrar como representar os elementos internos de um pacote existem

outras formas inclusive mais detalhadas como nós veremos também bom ah Aqui nós temos um outro exemplo de representação dos elementos interna de um pacote por meio do conector de aninhamento que é esse círculo com uma cruz interna então em situações em que os elementos não cabem dentro do pacote ou por uma opção gráfica pode-se utilizar o conjuntor de aliamento para determinar que determinados elementos estão eh contidos dentro de um determinado pacote eh Aqui nós temos um pacote contendo um modelo completo Aqui nós temos o módulo de modelo do sistema de controle bancar ário ou seja

o módulo que contém as classes de entidade H que são como eu falei classes relacionados diretamente ao domínio do problema e que contém a lógica do negócio Ah então Aqui nós temos todas as classes do módulo de modelo com mais detalhes onde eu estou detalhando os atributos e os métodos de cada classe bem como as associações que elas possuem entre si ah essa abordagem é perfeitamente válida o único problema é que elas ocupam um pouco mais de espaço em algumas situações pode não ser útil bom ah falar um pouquinho sobre nomes qualificados uma outra maneira

de demonstrar quando um pacote ou elemento está dentro de um outro pacote é por meio dos de nomes qualificados o nome qualificado basicamente ele mostra o pacote que contém outro pacote ou elemento separado por meio do símbolo de dois pontos Aqui nós temos o exemplo de nome qualificado onde eu tenho um pacote que contém o texto Sistema de Controle bancário 2 p do P módulo de modelo Isso significa que existe um pacote módulo de modelo que está contido no pacote Sistema de Controle bancário então aqui dentro do pacote módulo de modelo existe aqui um elemento

interno que representa a classe de entidade conta comum existem outras situações eh totalmente textuais em que eu posso criar um nome de qualificado completo onde eu colocaria lá ã o nome do pacote principal o nome do pacote interno e o nome de cada um dos elementos contidos Esse pacote todos separados por dois símbolos de dois pontos então eu poderia escrever Sistema de Controle bancário dois pontos dois pontos módulo de modelo dois pontos dois pontos conta comum isso significaria que o elemento conta comum estaria contido dentro do pacote módulo de modelo que estaria contido dentro do

Sistema de Controle bancário mas essa alternativa ela é totalmente textual ela não é gráfica por isso eu representei um nome qualificado eh parcial uma vez que o elemento conta comum está sendo representado graficamente Ahã Aqui nós temos um pacote contendo pacotes aqui eu tenho o mesmo módulo de modelo do sistema de controle bancário com as classes de entidade totalmente representadas E dentro dele eu tenho um pacote representando o as classes de repositório Então tem um sub pacote dentro pacote módulo de modelo Lembrando que o padrão repository é um padrão utilizado para auxiliar na persistência de

objetos Como já foi visto em outros vídeos então Aqui nós temos uma classe repositório para cada classe concreta do meu módulo de modelo nós vamos ver quando entrarmos no diagrama de sequência o fluxo de como funciona persistência entre classe de entidade classes de repositório e classes Dal os padrões reposit e já foram ensinados em vídeos anteriores sobre diagrama de classes eu vou falar um pouquinho sobre a associação de dependência basicamente essa Associação ela monstra que um pacote ou elemento interno possui uma dependência com outro pacote ou com outro elemento Ah então nós vamos ver alguns

exemplos disso aqui nós temos um exemplo simples dependência uma dependência representada por uma seta tracejada Aqui nós temos três sistemas Independentes poré integrados nós temos um sistema de contabilidade representado por um pacote um sistema de controle de estoque e um sistema de for pagamento o sistema de controle de estoque e o sistema de folha de pagamento eles possuem alguma forma de dependência com o sistema de contabilidade isso é representado por meio dessa ca tracejada então de alguma maneira o sistema de controle de estoque tem alguma dependência de alguma funcionalidade do sistema de contabilidade provavelmente é

necessário registrar todas as vendas e compras do sistema de controle de estoque e também todos os pagamentos feitos pela folha de pagamento o isso dependência entre esses sistemas integrados Ah dependências também pode trabalhar com eh estereótipos então eu posso por exemplo utilizar estereótipos dependências com estereótipos para representar a importação de elementos de um pacote para o outro então existem dois estereótipos que podem ser utilizados para isso que é o estereótipo exas e o estereótipo Import Ah o estereótipo exess ele ele permite a importação de um elemento Porém esse elemento ele não vai possuir visibilidade pública

Isso significa que esse elemento não será visível para outros elementos de fora do pacote somente para os elementos internos do pacote e também um outro pacote não poderá importar a aquele elemento do pacote em questão vai ter que Ele precisará importar ah a partir do pacote original já o o o estereótipo Import ele permite importar um elemento e esse elemento ele vai ser totalmente visível Isso significa que outros pacotes poderão enxergar esse elemento e poderão importá-lo Aqui nós temos o exemplo do uso de dependência com importação Aqui nós temos Sistema de Controle bancário e ele

e nós temos um outro pacote que é o pacote tipos Esse pacote tipos ele possui Ah três classes com estereótipo datee type Isso significa que elas representam tipos de dados então o tipo eu tenho um tipo de dados do tipo string um tipo de dados date e um tipo de dados time Ah quem assistiu outras aulas em que eu representava modelos conceituais e de domínios de classe do Sistema de Controle bancário irão lembrar que existem classes com atributos do tipo string do tipo date ou do tipo time e esses atributos eles estão esse tipo de

atributo está maiúsculo ISO significa que esses tipos não são tipos primitivos são tipos que na verdade representam uma classe e essa classe para ser corretamente utilizada ela precisa estar eh contida no diagrama em questão ou então ser importada de outro pacote Então o que eu estou fazendo aqui agora então o meu Sistema de Controle bancário pacote S de controle bancário ele está importando o tipo string e o tipo Date o tipo string tá sendo importado por meio de uma dependência com estereótipo access e o tipo date por meio de uma dependência com o estereótipo Import

basicamente ah os modelos os elementos do Sistema de Controle bancário vão poder utilizar os dois tipos de dados A diferença é que a visibilidade do tipo de dados string vai ser interna e a visibilidade do tipo de dados date vai ser eh pública outros elementos poderão enxergar esse tipo e poderão importá-lo por sua vez também é possível utilizar dependências para mesclar um pacote em outro por meio do estereótipo merch Isso significa que todos os elementos do pacote que está sendo mesclado vão ser eh mesclados vão ser incluídos no pacote que mesclou um exemplo disso é

visto nessa figura onde eu estou utilizando uma dependência com estereótipo merch então aqui eu estou dizendo que o sistema de controle bancário está está mesclando todos os elementos do pacote tipos dentro do seu próprio pacote então uma vez que eu tenho classes de entidade cujos atributos são do tipo string date e time é mais vantajoso eu mesclar todos os elementos do pacote tipos do que ficar importando cada um desses elementos um por um então eu utilizei uma dependência merge dizendo que eu estou mesclando todos os elementos dentro do meu pacote de Sistema de Controle bancário

também posso utilizar estereótipos h para aplicá-los diretamente a pacotes Lembrando que estereótipos são uma forma de atribuir características novas a um elemento ah ou Associação e existe estereótipos de texto estereótipos gráficos estereótipos de texto não modifica o desenho padrão São simplesmente texto entre sin de menor e maior e estereótipos gráficos modificam o de alguma de alguma maneira o desenho padrão do componente então aqui eu tenho dois estereótipos de texto que informam que o pacote ele representa um sistema ou um Framework ou seja um Arc bolso e aqui eu tenho dois estereótipos gráficos que demonstram que

o pacote representa um subsistema um sistema interno dentro de um sistema maior ah ou um modelo um módulo de um modelo como por exemplo eh o módulo de modelo mdulo de visão ou módulo de controle utilizados na arquitetura mvc bom continuando Aqui nós temos um diagrama de pacotes representando a arquitetura mvc a arquitetura mvc Como já foi visto em outros vídeos é viatura de Model View control ou seja modelo visão controle que é uma que é uma arquitetura em que os elementos do sistema são agrupados Então nós vamos ter um modo divisão que basicamente representa

classes que trabalham com a interação entre o os os usuários e o sistema eu vou ter um módulo de controle que contém as classes que vão interpretar os eventos que ocorrem sobre a visão e se necessário solicitar a execução de métodos pelas Class de entidade que são as classes de controle e eu vou ter um módulo de modelo que vai conter as classes de entidade classes que estão relacionados diretamente ao domínio do problema contém a lógica do negócio e em geral serão persistentes Então essa arquitetura cada um desses módulos foi representado por um pacote contendo

o estereótipo modelo quer dizer que ela contém elementos de um modelo ah ou seja cada uma delas representa o modulo de visão modo de controle e o módulo de modelo respectivamente e elas estão associadas por meio de associações de dependência então o módulo divisão e o módulo de controle possuem duas dependências entre si o módulo de divisão possui uma dependência com módulo de controle no momento que o módulo de visão precisa que o módulo de controle Interprete os eventos que ocorrem sobre a visão e o modo de controle tem uma dependência com modo de visão

no momento que ele necessita que as classes divisão ou melhor as instâncias das classes divisão apresentem formulários e informações que as instâncias das classes de controle julgarem pertinentes e o módulo de controle possui uma dependência com módulo de modelo no momento que as instâncias das classes de controle precisam que eh instâncias das classes de entidade contidas do modelo executem determinados métodos relacionados à lógica do negócio hã existem ainda duas dependências entre a visão e o modelo onde a visão ela pode em situações simples de simples atualização de dados solicitar que dados sejam atualizados diretamente ao

modelo e o modelo pode notificar a visão de que houve alguma alguma alteração nos dados e que a visão pode solicitar dar uma atualização desses dados aqui eu coloquei um ã uma nota deixando claro que essas situações se referem somente à atualização simples de dados em que não há necessidade de intermediação de uma controladora eh vocês vão notar que todos os elementos de cada um dos dos módulos está representado por meio de uma listagem essa é uma outra alternativa para representar os elementos internos de um pacote e que também particularmente no módulo de modelo existe

um pacote interno que representa as classes de repositório como já falei eh classe de repositório são classes que auxiliam na persistência de objetos na verdade a as classes repositório Não persistem realmente objetos elas gerenciam coleções de objetos em memória e eventual ente solicitam a persistência desses objetos para classes Dal eh isso já foi explicado em outros vídeos bom eh cabe aqui uma explicação com relação à arquitetura que está sendo representada existem muitas versões da arquitetura MDC eh vocês vão verificar alguma alguns exemplos de Arquitetura unvc em que não vão existir essas dependências entre a visão

e o modelo eh eu me baseei principalmente nos exemplos de arquitetura demonstrados pelo Ian summerfield pelo livro de engenharia de software do Ian Summer Onde existe esse esse relacionamento entre a visão e o modelo mas vocês vão ver outros autores que vão afirmar que não existe essas dependências entre essa dependência direta entre a visão e modelo que tudo tem que ser H gerenciado pela controladora bom eu adotei o padrão eh apresentado pelo iville então eu resolvi para deixar esse modelo mais próximo da arquitetura criar essas duas dependências onde o modelo notifica a visão de mudanças

de dados e a visão solicita a atualização desses dados diretamente quando é simples atualização de dados não há eventos por parte do do usuário que necessitem de interpretação das controladoras ah na verdade essa dependência de notificação de muda entre o modelo e visão não necessariamente precisaria estar sendo representado não é exatamente uma dependência é mais um aviso mas eu quis manter para deixar esse esse diagrama o mais próximo da representação da arquitetura mvc bom Aqui nós temos a mesma arquitetura só que eu acrescentei mais um pacote para representar a persistência das classes de entidade Ah

no seu formato original o padrão mvc tratava a persistência diretamente no modelo certo mas isso não é uma um uma boa escolha de projeto então o ideal é criar uma um módulo de persistência separado Então acrescentei esse módulo aqui criei mais um módulo para representar persistência então nessa nesse moddo de persistência estão as classes da que são classes que encapsulam a lógica para persistência ou seja gravação e recuperação ação de objetos em disco Então essas classes da cada uma dessas classes da encapsula a lógica para a persistência dos objetos das classes entidade em uma tabela

relacional eh aqui eu utilizei eh a terceira estratégia para mapeamento de hierarquias de classe em tabelas relacionais uma vez que o o módulo de modelo do sistema de controle bancário possui ah classes eh derivadas a partir de outras classes isso já foi explicado em vídeos anteriores sobre persistência de classes em tabelas relacionais bom então basicamente quando é necessário persistir os dados uma classe repositório irá solicitar a uma classe Dal que grave esse esses objetos em disco e eventualmente ela vai solicitar a recuperação desses objetos isso será demonstrado ã mais passo a passo quando nós entrarmos

no diagrama de sequência Aqui nós temos um outro exemplo do diagrama de pacotes representando agora uma arquitetura em camadas uma arquitetura em camadas não é a mesma coisa que a arquitetura mvc os módulos que compõem a arquitetura mvc Eles não estão em camadas eles possuem associações entre si mas não são exatamente uma arquitetura em camadas aqui nós estamos utilizando os mesmos pacotes um pacote visão um pacote controle um pacote modelo e um pacote persistência e organizando num Arquitetura em camadas Mas diferente da arquitetura um vc uma arquitetura em camadas ela permitiria a inserção de novos

pacotes entre essas camadas que estão sendo aqui representadas o que não seria possível na adoção da arquitetura mvc mas basicamente aqui o comportamento é essencialmente o mesmo porém ele é vertical a visão solicita algo pro controle o controle solicita algo pro modelo o modelo solicita alguma função para para o módulo de persistência para camada de persistência no caso a gravação e representação de objetos à Não existe uma ligação direta entre a visão e o modelo aqui tudo Obrigatoriamente passa pelo módulo de controle então no momento que a visão precisar apresentar alguma informação isso deve ser

solicitado ao controle que o controle vai disparar os métodos relacionados às classes de entidade e o retorno será ah interpretado pelo controle se ele achar necessário será apresentado nas classes de visão notem que não existe uma dependência entre o modelo e o controle somente do controle pro modelo porque basicamente o modelo eh simplesmente retorna os resultados da execução dos seus métodos quando solicitados ao controle o mesmo ocorre no caso da ah arquitetura mvc não existe uma dependência entre o modelo e o controle porque basicamente o modelo só vai retornar aos resultados das solicitações de execução

de métodos bom mas basicamente Aqui nós temos dois exemplos de aplicação de pacotes para representação de arquiteturas de projetos de software uma arquitetura mvc e uma arquitetura em camadas ah Possivelmente em outros vídeos nós vamos apresentar outros exemplos de arquiteturas utilizando esse diagrama então nós terminamos esse conteúdo eu espero que ele tenha sido útil espero que vocês tenham gostado se vocês gostaram desse vídeo eu peço que vocês curtam compartilhem se inscrevam no canal eu agradeço a atenção de vocês nós os vemos em outros vídeos obrigado pela atenção