Os analistas de software se deparam com a modelagem de sistemas grandes e muito complexos, porem pensando no desenvolvimento e manutenção futura, necessitam de algo que os auxiliem a não tornar essas tarefas muito complicadas.
Nos últimos tempos, surgem sistemas cada vez mais complexos, com estruturas de classes imensas e arquiteturas de camadas muito divididas. Para evitar com que o software se torne tão complexo ao ponto de se perder o “controle”, houve-se a necessidade de quebrar um grande complexo em menores partes de menor complexidade, principalmente para um entendimento mais fácil de quem irá desenvolver e dar manutenção nessas aplicações. Além da quebra em subpartes, houve a necessidade dessas subpartes interagirem entre si, pelos mesmos motivos descritos a cima.
Com isso veio o conceito definido pela UML diagrama de pacotes ou também conhecidos como diagramas de módulos. Esses diagramas têm como conceito agrupadores lógicos de pedaços dos sistemas (nível superior) com dependência entre eles (interação de pacotes), ou seja, pacotes podem depender de outros pacotes. Esses elementos agrupados podem ser diagramas, classes, outros pacotes, entre outros. Os pacotes sempre têm um nome próprio e dentro alguns elementos que são agrupados conforme os tipos de elementos descritos a cima. Na realidade, não existem propriamente diagramas de pacotes em UML, em vez disso, pacotes e relações entre pacotes aparecem noutros diagramas, de acordo com o tipo de pacote:
- Pacotes de classes (pacotes lógicos) – em diagramas de classes
- Pacotes de componentes – em diagramas de componentes
- Pacotes de nós – em diagramas de distribuição
- Pacotes de casos de utilização – em diagramas de casos de utilização
Existem nos diagramas de pacotes 3 tipos de dependências:
- Dependências Simples: Uma alteração do pacote destino influencia no pacote origem.
- Dependências <<access>>: O pacote origem acede a elementos exportados pelo pacote de destino.
- Dependências <<import>>: O conteúdo público do pacote de destino é adicionado ao pacote de origem.
Existem 3 tipos de visibilidades de elementos dentro dos pacotes:
- + (público) : visível por todos que importam ou acedem ao pacote.
- # (protegido): visível só pelos pacotes-filhos (por relação de generalização)
- – (privado): visível só por outros elementos do pacote.
Concluísse assim que diagramas de pacotes, são agrupadores genéricos de vários elementos vistos nos diagramas UML, tendo em vista deixar as aplicações com uma menor complexidade quebrando esses sistemas em subpartes menores, para uma fase de desenvolvimento mais tranquila, e para futuras manutenções se tornarem mais ágeis e “limpas”. Bem analisado e com o conceito de diagramas de pacotes bem maduro por quem for pensar, levantar os requisitos do sistemas e montar os diagramas possibilita as empresas terem softwares complexos e de fácil desenvolvimento e manutenção, permitindo uma agilidade na correção de bugs e realização de melhorias, aumentando o respeito do software no mercado e possibilitando o aumento de vendas e evitando ter aquele velho conhecido das empresas de softwares, que o código do “fulano” só ele sabe dar manutenção.
Pietro Zanandrea