UML - Processos e Ferramentas CASE

Capítulo 8 - UML – M ODELAÇÃO DA ARQUITECTURA
Tópicos
§
§
§
§
§
Introdução
Componentes e Nós
Diagramas de Componentes
Diagramas de Instalação
Exercícios
8.1 Introdução
Diagramas de arquitectura1 descrevem aspectos da fase de implementação e instalação
de um sistema de software, designadamente a estrutura e dependências de código
fonte e de módulos executáveis tal como a sua respectiva instalação nas diferentes
plataformas computacionais subjacentes. Estes diagramas apresentam-se sob duas
formas: diagramas de componentes e diagramas de instalação.
Os diagramas de componentes são usados para modelar a arquitectura de um
sistema de software da perspectiva dos seus componentes digitais (e.g., ficheiros de
código fonte, de executáveis, de configuração, tabelas de dados, documentos de gestão
do projecto), explicitando principalmente as suas dependências.
Os diagramas de instalação, por outro lado, são usados para modelar a arquitectura
de um sistema informático da perspectiva dos seus componentes fisícos/hardware (e.g.,
computadores, adaptadores de rede, impressoras, routers, cablagem), explicitando as
suas dependências de comunicação, assim como, que componentes são instaladas em
cada nó computacional.
Estes diagramas podem também ser aplicados na modelação de negócios e de
organizações caso se considere que as componentes de “código” sejam procedimentos
e regras de negócio e que os componentes não digitais constituam a infra-estrutura da
organização através de um conjunto de recursos (humanos e outros) do negócio.
(Na nossa opinião os diagramas de implementação constituem a parte mais limitada e
mal explanada do UML. Há inúmeros aspectos de desenho e de organização que a sua
1
A especificação 1.3 do UML designa-os por “diagramas de implementação”. Todavia, a
designação de “diagramas de arquitectura” parece-nos mais adequada tendo em conta que
estes diagramas podem ser aplicados no desenho de diferentes tipos de arquitecturas. Por
exemplo: arquitectura de sistemas de informação (que é a sua aplicação mais conhecida) ou
arquitectura de negócios e de organizações.
CENTRO ATLÂNTICO - COLECÇÃO T ECNOLOGIAS
2
actual versão não aborda, deixando-os em aberto, ao critério que os seus utilizadores
venham a definir, caso a caso. No lado oposto desta abordagem de flexibilidade e de
não definição, encontra-se, por exemplo, o EAB (Entreprise Application Blueprint)
[Boar98] que propõe uma notação muito completa e rigorosa para desenho de
arquitecturas de sistemas de informação, em particular para o desenho de sistemas,
plataformas e suas inter-relações.)
8.2 Componentes e Nós
8.2.1 Componentes
Uma componente representa uma peça de implementação de um sistema, na prática
um conjunto de artefactos fisícos em formato digital, por exemplo ficheiros de código
(fonte, binário ou executáveis) ou ficheiros de documentos relativos ao negócio.
Definem-se pelo menos três tipos distintos de componentes:
§
§
§
Componentes de instalação: constituem a base dos sistemas executáveis (e.g.,
DLL, executáveis, controlos Active-X, classes Java).
Componentes de trabalho: 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: criados como resultado da execução de um sistema
(e.g., processos, threads, agentes de software). Estes componentes são
representados nos diagramas de instalação.
Uma componente de software é uma parte física de um sistema: existe de facto num
determinado computador e não apenas na mente do analista, como acontece com o
conceito de classe. Adicionalmente, uma componente implementa uma ou mais classes,
as quais são representadas dentro do ícone de componente ou com relações explícitas
de dependência de implementação, conforme ilustrado na Figura 8.1.
Calculator
c:Calculator
Instância de
componente
(tipo de)
componente
wordProcessor.exe
Realiza
WordProcessor
SpellChecker
WordCounter
wordProcessor.exe
≈
WordProcessor
SpellChecker
WordCounter
Figura 8.1: Representação gráfica de componentes.
Elementos que residam em (i.e., sejam implementados por) uma componente são
apresentados dentro do símbolo da componente respectiva. Pode-se, se for
conveniente, representar o tipo de visibilidade desses elementos à semelhança do que
UML, PROCESSOS E F ERRAMENTAS CASE - BETA-BOOK
3
acontece com os pacotes. O significado da visibilidade depende do tipo de componente.
Por exemplo, se for uma componente com código fonte, pode corresponder a controlar
a acessibilidade aos seus construtores internos; se for uma componente com código
executável, a visibilidade pode corresponder à possibilidade de código de outras
componentes poderem aceder ou invocar o seu próprio código.
O desenvolvimento de software baseado em componentes pressupõe a existência de
componentes com um sentido mais restrito/exigente que este adoptado no UML. Ou
seja, a noção de “componente” em UML é lata, mas inclui naturalmente a noção de
componente de software encontrada por exemplo nas propostas do Java beans,
Enterprise Java beans, ou Active-X. Um aspecto importante ligado à noção de
componente tem a ver, como é analisado na Secção 6.4, com a noção de interface.
Tipicamente as componentes de software (as do sentido restrito acima referido)
implementam uma ou mais interfaces, e é através destas interfaces que providenciam
as suas funcionalidades a outras componentes. A Figura 8.2 ilustra a relação (de
realização) entre componentes e interfaces, tal como a relação de dependência entre
componentes, que se faz através do conceito de interface.
wordsmith.dll
wordProcessor.exe
ISpell
realização
(forma simples)
interface
dependência
«interface»
ISpell
wordProcessor.exe
wordsmith.dll
spell()
realização
(forma expandida)
Figura 8.2: Componentes e Interfaces.
A especificação 1.3 do UML identifica os seguintes estereótipos para componentes:
§
§
§
§
«document»: denota um documento.
«executable»: denota um programa que possa ser executado num nó.
«file»: denota um documento contendo código fonte ou dados.
«libary»: denota uma biblioteca dinâmica ou estática.
§
«table»: denota uma tabela de uma base de dados.
8.2.2 Nós
Um nó é um objecto fisíco que representa uma recurso de processamento, geralmente
tendo capacidades de memória e de processamento. Os nós podem consistir em
recursos computacionais (hardware), mas também em recursos humanos ou recursos
de processamento mecânico. Os nós podem ser representados como tipos e como
instâncias. Instâncias de nós podem conter instâncias de objectos e de componentes.
CENTRO ATLÂNTICO - COLECÇÃO T ECNOLOGIAS
4
Associação de
comunicação
Servidor
(tipo de) nó
Monitor
« Device »
lisboa004:Kiosk
« Processor »
instância de nó
Figura 8.3: Representação gráfica de nós.
Um nó é representado como um cubo 3-dimensional conforme ilustrado na Figura 8.3.
Dois nós podem-se encontrar ligados através de relações de associação. Estas
especificam a existência de caminhos de comunicação entre os correspondentes nós e
podem ser caracterizadas por um estereótipo de modo a explicitar o tipo de
comunicação envolvido (e.g., o tipo de canal ou o tipo de rede).
As propriedades dos nós (e.g., capacidade de memória principal, número de
processadores, data de aquisição, …) é representada por marcas com valores. Por
outro lado, podem-se definir estereótipos, com correspondentes ícones, para modelizar
diferentes tipos de recursos de processamento.
Para efeito dos exemplos descritos neste livro assume-se a existência de dois
estereótipos de nós para representação de recursos computacionais:
§
«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.
Assume-se que por omissão um nó é do estereótipo «processor» (e.g., nó Servidor
da Figura 8.3).
8.2.3 Relações entre Nós e Componentes
Um (tipo de) nó pode conter (tipos de) componentes. Tal facto pode ser traduzido pela
inclusão dos componentes no símbolo do nó, ou pelo estabelecimento de uma relação
de dependência, de estereótipo «support» entre o nó e as componentes suportadas,
conforme ilustrado na Figura 8.4.
UML, PROCESSOS E F ERRAMENTAS CASE - BETA-BOOK
5
Servidor
Servidor
Directório de Telefones
Programa de Pesquisa
≈
Servidor
Directório de
Telefones
≈
«support»
«support»
Programa de
Pesquisa
Programa de
Pesquisa
Directório de
Telefones
Figura 8.4: Relação entre nós e componentes.
Nós e componentes partilham um conjunto de semelhanças e diferenças. As
semelhanças são que ambos podem (1) participar em relações de generalização,
dependência e associação; (2) ser aninhados; (3) ter instâncias; e (4) participar em
interacções. As diferenças são que as (1) componentes são coisas que participam na
execução de um sistema; nós são coisas que suportam e executam componentes; e
que as (2) componentes representam agrupamento físico de elementos lógicos; nós
representam a instalação física de componentes.
8.3 Diagramas de Componentes
Um diagrama de componentes ilustra as dependências entre várias componentes de
software (incluam-se nesta definição lata, e entre outros: artefactos de código fonte, de
código binário, de código executável, procedimentos de negócio e documentos). Um
módulo de software pode ser representado por um estereótipo, por exemplo, para ter
uma apresentação gráfica distinta de outros tipos de componentes.
Um diagrama de componentes representa apenas tipos de componentes e nunca
instâncias de componentes. Para ilustrar instâncias de componentes deve ser usado um
diagrama de instalação (possivelmente uma versão simplificada sem nós).
Entre outras motivações para a construção de modelos de componentes, salientam-se
as seguintes:
§
§
§
Os clientes podem ver a estrutura final do sistema, mesmo antes deste estar
concluído.
A equipa de desenvolvimento tem uma visão da arquitectura física do sistema, pelo
que pode trabalhar de forma mais controlada e sistemática.
Os escritores técnicos (que produzem, por exemplo, a documentação do sistema,
manuais de utilizador, manuais técnicos) podem entender melhor sobre o que estão
a escrever, detalhar alguns aspectos do sistema, antes de este se encontrar
concluído.
Apresentam-se de seguida dois exemplos de aplicação de diagramas de componentes:
um que ilustra as dependências de artefactos físicos referenciados numa página HTML,
e um segundo exemplo que ilustra as dependências entre módulos de instalação
constituintes de uma aplicação típica do Windows.
6
CENTRO ATLÂNTICO - COLECÇÃO T ECNOLOGIAS
Exemplo 8.1: Diagrama de Componentes relativo a uma Página HTML.
Considere a página Web Example1.html com uma referência a um applet Java e com o seguinte
conteúdo:
<html>
<head>
<title>The Animator Applet (1.1) - example 1</title>
</head>
<body>
<h1>The Animator Applet (1.1) - example 1</h1>
<applet codebase="." code=Animator.class width=460 height=160>
</applet>
<a href="Animator.java">The source.</a>
<hr>
</body>
</html>
O diagrama de componentes correspondente a este “mini-sistema” consiste nos seguintes ficheiros:
example1.html, Animator.class, e Animator.java. A Figura 8.5 ilustra essas relações de
dependência. Note-se em particular a relação de dependência explícita entre a componente
Animator.java e a interface Java MouseListener.java definida no pacote java.awt.
Example1.html
Animator.class
Animator.java
java.awt.event
MediaTracker
MouseListener
Figura 8.5: Diagrama de componentes do Exemplo 8.1.
UML, PROCESSOS E F ERRAMENTAS CASE - BETA-BOOK
7
Exemplo 8.2: Diagrama de Componentes relativo à instalação de uma aplicação.
Considere a aplicação WinCOR desenvolvida sobre ambiente MS-Windows e responsável pela gestão de
correspondência (entrada e saída) de uma organização. A aplicação consiste num conjunto variado de
componentes de instalação, nomeadamente:
§
wincor.exe: ficheiro que contêm o executável da aplicação
§
pblib32.dll, sde32.dll, sdemdb32.dll: bibliotecas com código binário que providenciam
funcionalidades adicionais
§
wincor.hlp: ficheiro de ajuda sobre a aplicação.
§
wincor.ini: ficheiro de configuração da aplicação
§
entrada.db, saida.db: ficheiros/tabelas da base de dados de suporte
A Figura 8.6 ilustra o respectivo diagrama de componentes para a situação descrita. Note-se nas
dependências identificadas entre as diferentes componentes de instalação. Estas dependências referem que
o executável wincor.exe (i.e., a aplicação WinCOR) apenas pode correr se todas as restantes
componentes tiverem sido instaladas adequadamente e que o módulo sdemdb32.dll depende do módulo
sde32.dll.
«document»
«library»
cor.hlp
pblib.dll
«table»
entrada.db
«executable»
wincor.exe
{versão=3.2}
«document»
cor.ini
«table»
saida.db
«library»
«library»
sde32.dll
sdemdb.dll
Figura 8.6: Diagrama de componentes do Exemplo 8.2.
Neste exemplo houve o cuidado particular de se explicitar os estereótipos dos diferentes componentes
envolvidos.
CENTRO ATLÂNTICO - COLECÇÃO T ECNOLOGIAS
8
8.4 Diagramas de Instalação
Um diagrama de instalação ilustra a configuração dos elementos de processamento e
das componentes de software, processos e objectos neles suportados. Instâncias de
componentes de software representam manifestações de execução das unidades de
código.
Na modelação de negócios, os elementos de processamento são as unidades
organizacionais e os trabalhadores enquanto que as componentes de software são os
processos e documentos usados pelas unidades organizacionais e pelos trabalhadores.
Um diagrama de instalação consiste num conjunto de nós ligados por associações de
comunicação. Os nós podem conter instâncias de componentes (de execução), o que
significa que uma componente é instalada e executada num nó. Por outro lado, as
componentes são compostas por objectos (note-se que um processo é apenas um caso
particular de objecto: objecto activo).
Seguem-se dois exemplos de diagramas de instalação. O primeiro exemplo diz respeito
a uma versão simplificada do serviço 118 da Portugal Telecom numa versão
cliente/servidor. O segundo exemplo representa o equipamento hardware existente
tipicamente numa configuração doméstica.
Exemplo 8.3: Diagrama de Instalação do serviço 118 da PT.
Considere-se uma versão simplificada do serviço 118 da Portugal Telecom numa sua versão
cliente/servidor em que o cliente é uma aplicação previamente instalada e configurada num PC com MSWindows. (Nota: existe também este serviço na versão Web em http://net118.telecom.pt/).
118-servidor:Servidor
Directório de
Telefones
Programa de
Pesquisa
Resultados
:PC
*
Programa de
Apresentação 118
Figura 8.7: Diagrama de instalação do Exemplo 8.3.
Pelo facto do diagrama de instalação apresentar componentes, todos os elementos apresentados têm de ser
instâncias, neste caso são apresentadas instâncias de nós e de componentes. Outro aspecto relevante deste
exemplo é a representação neste diagrama de instalação da existência de vários PC através do carácter “*”
colocado no canto superior direito do nó “PC”.
UML, PROCESSOS E F ERRAMENTAS CASE - BETA-BOOK
9
Exemplo 8.4: Diagrama de Instalação do Sistema de Trabalho Doméstico.
A Figura 8.8 apresenta o diagrama de instalação correspondente a um sistema de trabalho doméstico
constituído por um PC, com alguns equipamentos adicionais, por exemplo: uma impressora, um monitor,
colunas de som, e um modem. O modem permite a ligação à Internet através de um determinado ISP
(Internet Service Provider).
Internet
«device»
Monitor
«processor»
ISP
«device»
Impressora
«processor»
PC
«device»
Modem
«device»
Coluna Som
Figura 8.8: Diagrama de instalação (de tipos) do Exemplo 8.4.
Caso se pretendesse ilustrar uma configuração particular do diagrama ilustrado e/ou ilustrar as
componentes de software que deveriam existir numa determinada configuração ter-se-ia de desenhar um
diagrama de configuração de nível de instâncias. A Figura 8.9 ilustra uma possível configuração
(instanciação) desenhada a partir do diagrama da Figura 8.8.
sTelepac:ISP
:Monitor
(ICL-5550)
meuPC:PC
:Modem
(Zoom 56K)
(PC XPTO, PIII
450MHz)
:Impressora
Windows 2000
Office 97
(HP LJ1100)
Netscape
Figura 8.9: Diagrama de instalação (de instâncias) do Exemplo 8.4.
CENTRO ATLÂNTICO - COLECÇÃO T ECNOLOGIAS
10
8.5 Exercícios
Ex.1. Pretende-se o diagrama de componentes correspondente ao programa expipes desenvolvido em linguagem C, com os seguintes módulos: ex-pipes.c
util.c server.c client.c, e com dependências definidas pelo seguinte
makefile:
CC = gcc
CFLAGS = -g
ex-pipes : ex-pipes.o util.o server.o client.o
$(CC) -g -o ex-pipes ex-pipes.o util.o server.o
client.o
Ex.2. Pretende-se o diagrama de componentes correspondente à página Web
http://www.tvi.pt/ com o seguinte conteúdo:
<html>
<head>
<meta http-equiv="content-type" content="text/html">
<title>TVI OnLine</title>
</head>
<frameset rows="296,*" border="0" frameborder="NO" framespacing="0">
<frame src="index_hdr.html" name="hdr" noresize>
<frame src="index_ix.html" name="ix" noresize scrolling="NO">
</frameset>
<noframes>
<body bgcolor="#000000" background="HmPG/imagens/directoIX_BG.jpg">
</body>
</noframes>
</html>
Tenha em consideração os componentes (ficheiros) representados a negrito.
Ex.3. Pretende-se o diagrama de instalação da infra-estrutura computacional de apoio
às suas aulas práticas.
(i)
Considere apenas os nós existentes e os seus tipos de comunicação.
(ii)
Alterar o diagrama produzido na alínea anterior de modo a incluir a
descrição dos postos de trabalho e as componentes de software mais
relevantes (e.g., servidor Web, ferramentas de trabalho (e.g., Rose,
VisualStudio), servidor BD, sistema operativo).
Ex.4. Considere o serviço 118 da PT conforme introduzido no Exemplo 8.3. Modifique
o exemplo dado tendo em consideração que o serviço é acedido através de um
cliente/browser Web.
UML, PROCESSOS E F ERRAMENTAS CASE - BETA-BOOK
11
Ex.5. Pretende-se o diagrama de instalação para modelizar a seguinte situação:
“Uma empresa industrial está estruturada em quatro departamentos: produção,
comercial, controlo da qualidade, e administrativo-financeiro. Cada um destes
departamentos tem um director respectivo. O director-geral é o responsável pela
coordenação e supervisão de todos os departamentos. O departamento
administrativo-financeiro está estruturado em duas secções, respectivamente a
secção administrativa e a secção financeira.”
Sugestões:
(1) Considere que os recursos do negócio (unidades orgânicas e as pessoas)
são nós do diagrama a desenhar.
(2) Represente, através de estereótipos, o tipo das associações existentes entre
nós.