Diagramas de pacotes
- 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