O documento discute pacotes em UML, incluindo diagramas de pacotes e tipos de pacotes como pacotes lógicos. Pacotes representam agrupamentos genéricos e podem conter elementos como classes e interfaces. Diagramas de pacotes mostram relações entre pacotes, como dependências. Pacotes lógicos dividem sistemas em módulos de responsabilidade.

1. UML – Diagramas de Pacotes (Packages)
e Modelação da Arquitectura Lógica
Profs: dr. Edgar Gemo
Dr. Zeferino Saugene (MSc.)

2. Pacotes
Um pacote (package) em UML é um mecanismo de
agrupamento genérico
Notação: pasta com o nome no interior ou na pega
No caso de um pacote contido noutro, o nome completo do
pacote contido inclui o nome do seu contentor
Client
Client Sensors::Vision

3. Diagramas de pacotes
Um diagrama de pacotes mostra pacotes e relações entre
pacotes
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

4. Pacotes lógicos
Um pacote lógico (ou módulo lógico) é um agrupamento lógico de
classes e relações entre essas classes
• divisão de um sistema em pacotes lógicos é uma divisão de responsabilidades
Corresponde ao conceito de package em Java ou de namespace
em C++ e C#
Não confundir com empacotamento físico do software em
ficheiros de código fonte, executáveis, dll's, etc. (designados
componentes em UML)
Um pacote lógico pode atravessar vários ficheiros
Diagramas de pacotes lógicos utilizadas para modelar a
arquitectura lógica de um sistema de software (organização em
módulos lógicos e especificação de interfaces e dependências
entre módulos)

5. Conteúdo de um pacote
Uma vez que representa um agrupamento, um pacote é em
geral dono de diversos elementos: classes, interfaces,
componentes, nós, colaborações, casos de uso, diagramas,
e até outros pacotes
Esses elementos podem ser indicados no interior do pacote,
na forma de uma lista de nomes ou diagrama
Client Client
+ OrderForm + OrderForm
+ TrackingForm - Order
- Order + TrackingForm
Um pacote forma um espaço de nomes
• classe Order do pacote Client é designada Client::Order

6. Visibilidade dos elementos contidos
num pacote
Pode-se indicar a visibilidade dos elementos:
+ (público) : visível por todos que importam ou acedem ao pacote
(nomes sem :: no 1º caso, com :: no 2º caso)
# (protegido): visível só pelos pacotes-filhos (por relação de
generalização - ver adiante)
- (privado): visível só por outros elementos do pacote
Os elementos públicos de um pacote são chamados também
os elementos exportados pelo pacote

7. Dependências entre pacotes
Dependência simples: uma alteração do pacote de destino
afecta o pacote de origem (dependente) (informação útil
para controlo de alterações)
Dependência com estereótipo «access»: o pacote de
origem (dependente) acede a elementos exportados pelo
pacote de destino (precisa de :: nos nomes)
Dependência com estereótipo «import»: o pacote de
origem (dependente) importa os elementos exportados pelo
pacote de destino (não precisa de :: nos nomes)
Client GUI
+ OrderForm + Window
+ TrackingForm «import» + Form
- Order # EventHandler

8. Generalização de pacotes
Usada para especificar famílias de pacotes relacionados por
herança
GUI
+ Window
+ Form
# EventHandler
herda sem alteração
(default)
WindowsGUI
substitui (overrides) + GUI::Window
o elemento Form de + Form MacGUI
GUI # GUI::EventHandler
+VBForm
adicionado
herda os elementos públicos e protegidos de GUI

9. Estereótipos em pacotes
«system» - pacote que representa o sistema completo que está a ser
modelado (incluindo todos os modelos e elementos dos modelos)
«subsystem» - pacote que representa uma parte independente de
sistema completo que está a ser modelado; corresponde normalmente a
um corte "vertical"
«facade» (fachada) - pacote que constitui uma vista sobre outro pacote
(não acrescenta funcionalidades, apenas apresenta de forma diferente)
«framework» (infra-estrutura aplicacional) - pacote que representa um
conjunto de classes abstractas e concretas concebido para ser estendido,
implementando a funcionalidade típica de um determinado domínio de
aplicação
«stub» - pacote que serve como proxy para o conteúdo público de outro
pacote
«layer» - pacote que representa uma camada horizontal de um sistema

10. Composição de pacotes (1)
Sub-pacotes podem ser indicados dentro do pacote-dono ou
com relação de composição
«system»
Retail Enterprise System
«subsystem» «subsystem» «subsystem»
Customer In Store Warehouse
Service Management Management
subsystem subsystem subsystem
Neste exemplo segue-se uma divisão vertical, por subsistemas!

11. Composição de pacotes (2)
«system»
Retail Enterprise System
«layer» Graphical User Interface
Retail Enterprise System - GUI
«layer»
Business Logic
Retail Enterprise System - BL
«layer» Database
Retail Enterprise System - DB
Neste exemplo segue-se uma divisão horizontal, por camadas!

12. Caso de estudo (biblioteca): divisão em
áreas funcionais
<<subsystem>>
<<subsystem>>
Relação com Clientes
Relação com
(Leitores e Sócios)
Fornecedores
<<subsystem>>
Gestão de Recursos
(Publicações)

13. Caso de estudo (biblioteca): divisão em
camadas técnicas
<<layer>>
Interface com o
Ut ilizador
<<layer>>
Lógica de
Negócio
<<layer>>
Base de Dados

14. Caso de estudo (biblioteca): divisão em
camadas técnicas e áreas funcionais
IU - Clientes IU - Recursos
Lógica de Negócio - Lógica de Negócio -
Clientes Recursos
(from Ló gica de Negócio) (from Lógica de Negócio)
Base de Dados - Base de Dados -
Clientes Recursos