UML – Diagramas de Componentes e Modelação da Arquitectura Física

Diagrama de Componentes Captura a estrutura física da implementação Construído como parte da especificação da arquitectura Objectivo Organizar o código fonte (ambiente de desenvolvimento) Construir uma release executável (ambiente de produção) Especificar uma base de dados física Desenvolvido por arquitectos e programadores Contém componentes, interfaces e relações entre componentes Pacotes de componentes podem ser usados para modelar a arquitectura física

Componentes Um componente é uma parte física (feita de bits e bytes) e substituível de um sistema, que proporciona a realização de um conjunto de interfaces Podem-nos interessar diferentes ambientes: desenvolvimento, produção, testes, ... Exemplos: executáveis, bibliotecas, tabelas, ficheiros, documentos Um componente representa um empacotamento físico de elementos relacionados logicamente (normalmente classes) Notação: caixa com tabs kernel32.dll

Tipos de componentes - ícones e estereótipos <<executable>> componente que pode ser executado num nó <<library>> biblioteca estática ou dinâmica <<database>> base de dados <<table>> tabela de uma base de dados <<file>> ficheiro contendo código fonte ou dados <<document>> documento genérico 2 rodas dentadas

Interfaces Uma interface é um conjunto de operações usado para especificar os serviços de uma classe ou componente Relação de concretização (realization): um componente pode concretizar (implementar os serviços de) uma ou mais interfaces Normalmente quer dizer que tem classes que implementam esses interfaces Diz-se que as interfaces são exportadas Um componente poder ser substituído por outro componente que implementa as mesmas interfaces Não basta obedecer à mesma sintaxe, mas também à mesma semântica Relação de dependência: um componente pode usar uma ou mais interfaces Diz-se que essas interfaces são importadas Um componente que usa outro componente através de uma interface bem definida, não deve depender da implementação (do componente em si), mas apenas da interface

<<interface>> Interfaces – Exemplo 1 image.java componente.java ImageObserver ou com mais detalhe: dependência interface concretização image.java componente.java <<interface>> ImageObserver abort: int {final static} error: int {final static} imageUpdate(): Boolean

Visual Basic Application (mais precisamente, API) Interfaces – Exemplo 2 Java Application componente JDBC Visual Basic Application Sun JDBC-ODBC brigde SQL Server JDBC driver interface (mais precisamente, API) ODBC Oracle ODBC driver SQL Server ODBC driver Transact SQL SQL Server DBMS

Tipos de dependências entre componentes Dependências simples: entre ficheiros com código fonte, para controlo de alterações entre executáveis e/ou bibliotecas, para gestão de configurações e dependências entre executáveis ou bibliotecas e tabelas ou documentos de ajuda por eles usados Dependências estereotipadas: estereótipo «hyperlink» - entre páginas html ou páginas html e executáveis estereótipo «trace» - entre versões consecutivas do mesmo tipo de componente Não esquecer que é melhor depender das interfaces do que das implementações

Dependências - Exemplo

Composição e agrupamento de componentes Conforme o nome indica, os componentes são para compor (montar), criando componentes maiores ou sistemas inteiros Exemplos: Base de dados composta por tabelas Biblioteca dinâmica (dll) composta por componentes COM+ No caso de agrupamentos de componentes que não criam componentes (físicos) maiores, usar pacotes de componentes Base de dados de biblioteca Web site «hyperlink» Tabela de sócios Tabela de reservas Tabela de publicações Web page 1 Web page n

Caso de estudo (biblioteca) Pacotes de componentes

Caso de estudo (biblioteca) Todos os componentes Páginas Web Dinâmicas do SIB Segue um padrão! Qual é? Como formalizar? O padrão é arquitectura! Componentes de Lógica de Negócio do SIB Base de Dados do SIB