View
6
Download
0
Category
Preview:
Citation preview
25-5-2004 Diagramas de Componentes e Diagramas de Instalação elsa.cardoso@iscte.pt
25 Maio 2004
�������������� ��������������������� ��������������������� ��������������������� ��������������������� ��������������������� ��������������������� ��������������������� ������������������� ����� �� � �������������� ����� �� � �������������� ����� �� � �������������� ����� �� � �������������� ����� �� � �������������� ����� �� � �������������� ����� �� � �������������� ����� �� � ��
� � � �� ����� � � �� ����� � � �� ����� � � �� ����� � � �� ����� � � �� ����� � � �� ����� � � �� ����
Elsa Cardoso, DCTI Elsa Cardoso, DCTI -- ISCTEISCTE
elsa.cardoso@iscte.pt
25-5-2004 Diagramas de Componentes e Diagramas de Instalação elsa.cardoso@iscte.pt
Sumário
2
Conceitos UML
Perspectiva de Desenho do Sistema:
Diagrama de classes numa perspectiva de Desenho:EstereótiposRelação de DependênciaRelação de RealizaçãoInterfaces
Reutilização:1. Interfaces para classes2. Camadas (layers) no diagrama de classes3. Pacotes
Noção de Componente e Nó
Diagramas de Componentes e de Instalação
25-5-2004 Diagramas de Componentes e Diagramas de Instalação elsa.cardoso@iscte.pt
Desenho do Sistema
3
A fase de Desenho procura determinar COMO é que o sistema cumpre os requisitos
- O diagrama de classes é refinado ao nível de Desenho
REUTILIZAÇÃO
Grande objectivo do desenvolvimento orientado por objectos, onde se procura produzircomponentes reutilizáveis, que possam ser utilizados em diferentes aplicações,
diminuindo os custos de desenvolvimento
25-5-2004 Diagramas de Componentes e Diagramas de Instalação elsa.cardoso@iscte.pt
Refinamento do Diagrama de Classes
4
Mecanismo de extensibilidade que permite aumentar a flexibilidade dasclasses, através de uma subclassificação
É possível criar novos estereótipos
Os mais utilizados são: <<interface>> e <<control>>
1. Estereótipo
Gestão
criar()apagar()ver()
<<Interface>>
ControloAcesso
verificaAcesso()
<<control>>
GestãoControloAcess o
Classe com um conjunto de regras que controlamdeterminadas operações do sistema e que coordenam
as interacções com as outras classes.
Conceitos UML
25-5-2004 Diagramas de Componentes e Diagramas de Instalação elsa.cardoso@iscte.pt 5
Utilizada quando uma classe recorre aos serviços disponibilizados por outra classe, numa relação de cliente/fornecedor de serviços
2. Noção de Dependência
Funcionario
binomemorada
Gestão
EncomendanumeroEdatatipoEncomenda
criar()apagar()ver()
Relação de Dependência
A classe Funcionario depende (ou usa alguma funcionalidade) da classe Encomenda através da interface Gestão
Refinamento do Diagrama de Classes Conceitos UML
25-5-2004 Diagramas de Componentes e Diagramas de Instalação elsa.cardoso@iscte.pt 6
Utilizada na modelação de um contrato entre uma classe que especifica o serviço euma outra classe que garante a realização do serviço.
Estabelece-se entre uma interface e uma classe ou entre uma interface e um componente.
Mistura entre a relação de generalização e a de dependência (ver notação)
3. Noção de Realização
Relação de Realização (forma expandida)
Funcionario
binomemorada
Gestão<<Interface>>
EncomendanumeroEdatati poEn comen da
criar()apaga r()ver()
Funcionario
binomemorada
Gestão
EncomendanumeroEdatatipoEncomenda
criar()apagar()ver()
Relação de Realização (forma simples)
Refinamento do Diagrama de Classes Conceitos UML
25-5-2004 Diagramas de Componentes e Diagramas de Instalação elsa.cardoso@iscte.pt 7
Uma interface é um grupo de operações que são utilizadas para especificar um serviço.Este serviço funciona como um contrato entre a classe e os seus clientes
Mecanismo para separação entre a vista externa e a vista interna de um determinado elemento usual nas linguagens de programação baseadas em objectos
Uma interface é realizada (ou implementada) por uma ou mais classes, as quais prometem implementar todos os métodos nela especificados
4. Interface
Conceito associado ao desenvolvimento de software baseado em componentes
Refinamento do Diagrama de Classes Conceitos UML
25-5-2004 Diagramas de Componentes e Diagramas de Instalação elsa.cardoso@iscte.pt 8
Captura de semelhanças entre classes não relacionadas sem forçar a criação de relações artificiais entre elas;
Declaração de métodos que uma ou mais classes esperam implementar;
Revelar a interface de programação de um objecto sem revelar a sua classe. I.e., um objecto pode ser visto de diferentes perspectivas (ou diferentes tipos) consoante as situações.
4. Interface – benefícios ao nível da programação
Refinamento do Diagrama de Classes Conceitos UML
25-5-2004 Diagramas de Componentes e Diagramas de Instalação elsa.cardoso@iscte.pt
Uma classe pode conter várias interfaces, fornecendo assim diferentes abstracções dos seus serviços, conforme o cliente.
4. Interface – exemplo
Funcionariobinomemorada
Gestão
criar()apagar()ver()
<<Interface>>
EncomendanumeroE : Longdata : DatetipoEncomenda : StringvalorTotal : Long
criar()apagar()ver()adicionaProduto()calculaValorTotal()
Clientebi : Stringnome : Stringmorada : String
preRegisto()
Visualizar
ver()
<<Interface>>
Refinamento do Diagrama de Classes Conceitos UML
9
25-5-2004 Diagramas de Componentes e Diagramas de Instalação elsa.cardoso@iscte.pt
Desenho do Sistema
10
Algumas estratégias possíveis para, ao nível do Desenho, promover a reutilização:
REUTILIZAÇÃO
• Interfaces para classes
• Camadas (layers) no diagrama de classes
• Pacotes
25-5-2004 Diagramas de Componentes e Diagramas de Instalação elsa.cardoso@iscte.pt
Camadas (layers) no Diagrama de Classes
Três camadas de serviços
1. Serviços de Interface ou User services– fornece a interface do utilizador para apresentação e recolha de dados
2. Serviços de Negócio ou Business services– engloba as classes que possuem as regras fundamentais do negócio
3. Serviços de Dados ou Data services– permite manter, actualizar e aceder aos dados persistentes
Reutilização
11
25-5-2004 Diagramas de Componentes e Diagramas de Instalação elsa.cardoso@iscte.pt
Caso de Estudo: PhonePizza Ex. Diagrama de Classes com 3 níveis
12
Ecrã Pré-registo<<user interface>>
Ecrã Reservas<<user interface>>
Ecrã Encomendas<<user interface>>
Controlo Acesso
verificaAcesso()
SD_Clientebinomemorada
criar()apagar()consultar()actualizar()
<<data connection>>
SD_EncomendanumeroEdatatipoEncomenda
criar()apagar()consultar()actualizar()
<<data connection>>*
1
*
1efectua
Cliente {persistence=yes}binomemorada
pre-registo()
Encomenda {pers istence=yes}numeroEdatatipoEncomenda
criar()
*
1
*
1
efectua
Serviços de Dados
Serviços de Interface
Serviços de Negócio
25-5-2004 Diagramas de Componentes e Diagramas de Instalação elsa.cardoso@iscte.pt
Pacotes – organização de artefactos
Um pacote (package) em UML permite agrupar elementos de modelação (diagramas, classes, componentes, interfaces, etc) de um sistema de forma
a que semântica ou estruturalmente faça sentido
Reutilização
13
Gestão de Clientes
Controlo de Acesso
Gestão de Encomendas
Gestão de Produtos
Vantagens:
(1) Facilita a gestão e procura de artefactos(2) Evita os conflitos de nomes
(Ex: X::A é � de Z::A)(3) Providencia um mecanismo de controlo de
acessos (visibilidade)
Pública: “+”,Privada: “-” e Protegida: “#”
Encomendas Internet
+ FormEncomenda+ FormCatalogo- Encomenda
25-5-2004 Diagramas de Componentes e Diagramas de Instalação elsa.cardoso@iscte.pt
Relações entre Pacotes
VISIBILIDADE
Reutilização
14
Um elemento com Visibilidade Pública (“+”)– pode ser usado/referenciado por qualquer outro elemento independentemente do local onde é definido
Um elemento com Visibilidade Privada (“-”)– pode ser usado/referenciado por elementos definidos no mesmo pacote
Um elemento com Visibilidade Protegida (“#”)– pode ser usado/referenciado por um elemento definido no mesmo pacote ou num outro pacote que seja
uma especialização do primeiro
Tipos de Relações entre Pacotes: Importação, Exportação e Generalização
25-5-2004 Diagramas de Componentes e Diagramas de Instalação elsa.cardoso@iscte.pt
Relações entre Pacotes Reutilização
15
Relação de Exportação:
Um pacote faz a exportação, por definição, de todos os seus elementos públicos.
Isso não implica que um elemento definido noutro pacote possa aceder/referenciar um elemento exportado.Tem que existir explicitamente uma relação de importação entre os dois pacotes.
Relação de Importação:
É uma relação de dependência entre pacotes, especificando que o pacote base importa todos os elementos públicos definidos no pacote destino.Note-se que esta relação não é simétrica!
Preferencialmente, os elementos exportados por cada pacote devem ser do tipo interface.
25-5-2004 Diagramas de Componentes e Diagramas de Instalação elsa.cardoso@iscte.pt
Relações entre Pacotes Reutilização
16
Gestão de Clientes
Controlo de Acesso
Gestão de Encomendas
Gestão de Produtos
Relação de Importação (exemplo)
25-5-2004 Diagramas de Componentes e Diagramas de Instalação elsa.cardoso@iscte.pt
Relações entre Pacotes Reutilização
17
Relação de Generalização:
usada para a especificação de famílias ou hierarquias de pacotes, típicas em sistemas complexo (máximo 3 níveis!...)
Encomendas Internet
Encomendas Central
Encomendas Telefone
Encomendas Pizzaria
Gestão de Encomendas
HIERARQUIA DE PACOTES
25-5-2004 Diagramas de Componentes e Diagramas de Instalação elsa.cardoso@iscte.pt
Noção de Componente
18
Noção Geral:
Uma componente é uma entidade que possa ser reutilizada. [Silva2001]Exemplos:
• Conjunto de classes C++ (implementação)• Conjunto de use cases (nível especificação de requisitos)• Conjunto de diagramas de classes (nível de análise ou de desenho)
Desde que tenham sido definidos de forma a serem reutilizáveis!...
Definição [Silva, 2001]
Uma componente é uma peça básica na implementação de um sistema.Consiste num conjunto de artefactos físicos em formato digital, como por exemplo:
- ficheiros de código (fonte, binário ou executáveis)- ficheiros de documentos relativos ao negócio.
25-5-2004 Diagramas de Componentes e Diagramas de Instalação elsa.cardoso@iscte.pt
Definição de Componente: [SCREEN, 1996]
A component is any object or collection of objects that is a unit of construction and reuse.It has a purpose of existence, certain behaviour, interacts with the external world,
and can be controlled.
Definição [Nunes, 2003]
Uma componente de software representa um módulo físico de código.
Definição de Componente de Software: [Schmuller, 1999]
A software component is a physical part of a system. It resides in a computer, not in the mind of the analyst. Examples: table, data files,
executable, dynamic link library, document, ...
Noção de Componente
19
25-5-2004 Diagramas de Componentes e Diagramas de Instalação elsa.cardoso@iscte.pt
Diagrama de Componentes
20
Objectivo
Os diagramas de Componentes utilizam-se para modelar a arquitectura de um sistemade software na perspectiva dos seus componentes digitais, explicitando as relações de dependência entre as várias componentes de software.
Um diagrama de componentes representa apenas tipos de componentes,NUNCA instâncias de componentes.
As instâncias de componentes devem ser representadas num diagrama de Instalação
Controlo Acesso
25-5-2004 Diagramas de Componentes e Diagramas de Instalação elsa.cardoso@iscte.pt
Componentes e Classes
21
Uma componente é uma implementação em software de uma classe.
Uma classe representa uma abstracção de um conjunto de atributos e operações.
Uma componente pode ser a implementação de várias classes.
25-5-2004 Diagramas de Componentes e Diagramas de Instalação elsa.cardoso@iscte.pt
Componentes e Interfaces
22
Uma interface é um conjunto de operações que uma classe apresenta às outrasclasses.
A interface que uma classe usa é a mesma interface que a respectivaimplementação de software (a componente) usa.
Em UML não há distinção de interfaces conceptuais e físicas.
ControloAcesso<<DLL>>
Internet
25-5-2004 Diagramas de Componentes e Diagramas de Instalação elsa.cardoso@iscte.pt
Três Tipos de Componentes: Instalação, Trabalho e Execução
• Componentes de Instalação (Deployment Components):constituem a base dos sistemas executáveis (e.g., DLL, executáveis, classes Java)
• Componentes de Trabalho (Work Product Components):a partir dos quais são criados os componentes de instalação (e.g., ficheiros com código fonte, ficheiros de dados, documentos)
• Componentes de Execução (Execution Components):criados como resultado da execução de um sistema (e.g., processos, threads, agentes de software) – apenas representadas nos Diagramas de Instalação (Deployment diagrams).
Tipos de Componentes
23
25-5-2004 Diagramas de Componentes e Diagramas de Instalação elsa.cardoso@iscte.pt
Estereótipos para Componentes
24
<<document>>– denota um documento
<<executable>> – denota um programa que possa ser executado num nó
<<file>>– denota um documento que contém código fonte ou dados
<<library>>– denota uma biblioteca dinâmica ou estática
<<table>> – denota uma tabela de uma base de dados
25-5-2004 Diagramas de Componentes e Diagramas de Instalação elsa.cardoso@iscte.pt
Diagrama de Componentes
25
Um exemplo
Considere a aplicação WinCOR desenvolvida sobre MS-Windows responsável pela gestão (entrada e saída) da correspondência de uma empresa.A aplicação consiste no seguinte conjunto de componentes de instalação (deployment components):
• wincor.exe – ficheiro com o executável da aplicação• pblib32.dll, sde32.dll, sdemdb32.dll – bibliotecas com código binário com funcionalidades adicionais• wincor.hlp – ficheiro de ajuda da aplicação• wincor.ini – ficheiro de configuração da aplicação• entrada.db, saida.db – ficheiros/tabelas da base de dados de suporte
Desenhe o Diagrama de Componentes desta aplicação, tendo em atenção que (1) o executável só pode correr se todos os restantes componentes tiverem sido instalados; e (2) o módulo sdemdb32.dll depende do módulo sde32.dll.
25-5-2004 Diagramas de Componentes e Diagramas de Instalação elsa.cardoso@iscte.pt
Diagrama de Componentes
26
Um exemplo
wincor.hlp<<document>>
wincor.ini<<document>>
pblib.dll<<library>>
entrada.db<<table>>
saida.db<<table>>
sde32.dll<<library>>
sdem32db.dll<<library>>
wincor.exe<<executable>>
25-5-2004 Diagramas de Componentes e Diagramas de Instalação elsa.cardoso@iscte.pt
Noção de Nó
27
Um nó é um objecto físico que representa um recurso de processamento.
Os nós podem consistir em recursos computacionais (hardware), e recursos deprocessamento mecânico.
Os nós podem ser representados como tipos e como instâncias. Instâncias de nóspodem conter instâncias de objectos e de componentes.
Monitor<<device>>lisboa004:Kiosk
<<processor>>
Nó(instância
de nó)
Nó(tipo de nó)
25-5-2004 Diagramas de Componentes e Diagramas de Instalação elsa.cardoso@iscte.pt
<<processor>>– denota um nó que pode executar uma componente de software
<<device>> – denota um nó que não tem capacidade para executar componentes de software; e.g., uma impressora,
um scanner, ou um monitor.
Dois nós podem estar ligados através de relações de associação, que especificam a existência de caminhos de comunicação entre eles.
As comunicações podem ser caracterizadas por um estereótipo, indicando o tipo de comunicação envolvido (e.g., o tipo de canal ou o tipo de rede).
As propriedades dos nós são representadas por marcas com valores. Podem também ser definidos ícones para modelar diferentes tipos de recursos de processamento.
Os nós podem ser classificados através de estereótipos, para representar com maisdetalhe os recursos físicos:
28
Noção de Nó
25-5-2004 Diagramas de Componentes e Diagramas de Instalação elsa.cardoso@iscte.pt
Diagrama de Instalação* (Deployment Diagram)
29
Objectivo
Os diagramas de Instalação utilizam-se para descrever a arquitectura de um sistemade software em termos de hardware e a sua relação com os diferentes componentes (software)
As componentes têm que ser executadas em algum recurso computacional que contenha memória e um processador.
O Diagrama de Instalação define em que recursos os diferentes componentes estarão localizados e processados
*Também denominadosDiagramas de Distribuição
Servidor http Servidor Encomendas Central
TCP/IP - XMLNó
(tipo de nó)
Comunicação
25-5-2004 Diagramas de Componentes e Diagramas de Instalação elsa.cardoso@iscte.pt
UML – Metodologias e Ferramentas CASEAlberto Silva, Carlos Videira, Edições Centro Atlântico, 2001.
Fundamental de UML, 2ª ed. Mauro Nunes, Henrique O’Neill, FCA, 2003
UML in 24 Hours.Joseph Schuller, SAMS Macmillan Computer Publishing, 1999
Referências
Recommended