cadeiras.iscte.ptcadeiras.iscte.pt/cdsi/fich/diagramascomponentes.pdf · 2005. 5. 16. · diagrama...

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

Sumário

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

Desenho do Sistema

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

Refinamento do Diagrama de Classes

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

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

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

Relação de Realização (forma simples)

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

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

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

<<Interface>>

EncomendanumeroE : Longdata : DatetipoEncomenda : StringvalorTotal : Long

criar()apagar()ver()adicionaProduto()calculaValorTotal()

Clientebi : Stringnome : Stringmorada : String

preRegisto()

Visualizar

<<Interface>>

Desenho do Sistema

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

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

Caso de Estudo: PhonePizza Ex. Diagrama de Classes com 3 níveis

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>>*

1efectua

Cliente {persistence=yes}binomemorada

pre-registo()

Encomenda {pers istence=yes}numeroEdatatipoEncomenda

criar()

efectua

Serviços de Dados

Serviços de Interface

Serviços de Negócio

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

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

Relações entre Pacotes

VISIBILIDADE

Reutilização

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

Relações entre Pacotes Reutilização

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.

Gestão de Clientes

Controlo de Acesso

Gestão de Produtos

Relação de Importação (exemplo)

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

HIERARQUIA DE PACOTES

Noção de Componente

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.

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

Diagrama de Componentes

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

Componentes e Classes

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.

Componentes e Interfaces

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

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

Estereótipos para Componentes

<<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

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.

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>>

Noção de Nó

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ó)

<<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:

Noção de Nó

Diagrama de Instalação* (Deployment Diagram)

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

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

cadeiras.iscte.ptcadeiras.iscte.pt/cdsi/fich/diagramascomponentes.pdf · 2005. 5. 16. · diagrama...

Documents

estrutura de manual cype -...

estrutura de manual cype -...

manual do utilizador - top...

cypeplumbing sanitary systems - top...

(un pase de...

fich ortogragfia am_an

e construção manual do utilizador - top...

infraestruturas urbanas - manual do...

estrutura de manual cype -...

1 - range(cell) -...

memoriaefuturo.cm-barreiro.ptmemoriaefuturo.cm-barreiro.pt/arq/fich/jornal_junior_11.pdf ·...

(fatec 1999) considere as afirmações: ii-

fich aval emeio-abril

infraestruturas urbanas - memória de...

fich matilde leão_2

revisões de...

considere um condutor metálico em equilíbrio...

passagens inferiores - manual do...

estrutura de manual cype -...

levy_cibercultura considere esse