UML – M
ODELAGEM DA
A
RQUITETURA
Tópicos Introdução Componentes e Nós Diagramas de Componentes Diagramas de Instalação Exercícios1 Introdução
Diagramas de arquitetura1descrevem 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 arquitetura de um
sistema de software da perspectiva dos seus componentes digitais (e.g., arquivos de código fonte, de executáveis, de configuração, tabelas de dados, documentos de gestão do projeto), explicitando principalmente as suas dependências.
Os diagramas de instalação, por outro lado, são usados para modelar a arquitetura de um sistema informático da perspectiva dos seus componentes físicos/hardware (e.g., computadores, adaptadores de rede, impressoras, routers, cabeamentos), 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 modelagem 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 arquitetura” parece-nos mais adequada tendo em conta que
estes diagramas podem ser aplicados no desenho de diferentes tipos de arquiteturas. Por exemplo: arquitetura de sistemas de informação (que é a sua aplicação mais conhecida) ou
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 arquiteturas de sistemas de informação, em particular para o desenho de sistemas, plataformas e suas inter-relações.)
2 Componentes e Nós
2.1 Componentes
Uma componente representa uma peça de implementação de um sistema, na prática um conjunto de artefatos físicos em formato digital, por exemplo arquivos de código (fonte, binário ou executáveis) ou arquivos 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, controles Active-X, classes Java).
Componentes de trabalho: a partir dos quais são criados os componentes de instalação (e.g., arquivos com código fonte, arquivos 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 fato 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 1.
(tipo de) componente
Calculator c:Calculator Instância de componente wordProcessor.exe Realiza WordProcessor SpellChecker WordCounter
Η
WordProcessor wordProcessor.exe SpellChecker WordCounterFigura 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
Uniban – Sistemas de Informação 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 adotado 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 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.
wordProcessor.exe dependência ISpell wordsmith.dll realização (forma simples) interface wordProcessor.exe «interface» ISpell spell() wordsmith.dll realização (forma expandida)
Figura 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.
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.
Associação de comunicação
Servidor
(tipo de) nó Monitor
« Device »
sp004:Kiosk
« Processor »
instância de nó
Figura 3: Representação gráfica de nós.
Um nó é representado como um cubo 3-dimensional conforme ilustrado na Figura 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 modelar 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 3).
2.3 Relações entre Nós e Componentes
Um (tipo de) nó pode conter (tipos de) componentes. Tal fato 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 4.
Servidor
Uniban – Sistemas de Informação
Servidor Servidor
Η
Directório deΗ
5 Directório de Telefones Programa de Pesquisa Programa de Pesquisa Telefones «support» Programa de Pesquisa «support» Directório de TelefonesFigura 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 interaçõ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.
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: artefatos 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 arquitetura 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 artefatos 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.
Exemplo 1: Diagrama de Componentes relativo a uma Página HTML.
Considere a página Web Example1.html conteúdo:
<html> <head>
com uma referência a um applet Java e com o seguinte
<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 arquivos: example1.html, Animator.class, e Animator.java. A Figura 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 java.awt.event Animator.java MediaTracker MouseListener
Uniban – Sistemas de Informação
Exemplo 2: Diagrama de Componentes relativo à instalação de uma aplicação.
7
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: arquivo 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: arquivo de ajuda sobre a aplicação. wincor.ini: arquivo de configuração da aplicação
entrada.db, saida.db: arquivos/tabelas da base de dados de suporte
A Figura 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» cor.hlp «document» cor.ini «library» sde32.dll «executable» wincor.exe {versão=3.2} «library» pblib.dll «library» sdemdb.dll «table» entrada.db «table» saida.db
Figura 6: Diagrama de componentes do Exemplo 2.
Neste exemplo houve o cuidado particular de se explicitar os estereótipos dos diferentes componentes envolvidos.
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 objetos neles suportados. Instâncias de componentes de software representam manifestações de execução das unidades de código.
Na modelagem 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 objetos (note-se que um processo é apenas um caso particular de objeto: objeto 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 Telefonica numa versão
cliente/servidor. O segundo exemplo representa o equipamento hardware existente tipicamente numa configuração doméstica.
Exemplo 3: Diagrama de Instalação do serviço 118 da Telefonica.
Considere-se uma versão simplificada do serviço 118 da Telefonica numa sua versão
cliente/servidor em que o cliente é uma aplicação previamente instalada e configurada num PC com MS- Windows. (Nota: existe também este serviço na versão Web em http://net118.telefonica.net/).
118-servidor:Servidor Directório de Telefones Programa de :PC Programa de *
Pesquisa Resultados Apresentação 118
Figura 7: Diagrama de instalação do Exemplo 3.
Pelo fato 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”.
Uniban – Sistemas de Informação
Exemplo 4: Diagrama de Instalação do Sistema de Trabalho Doméstico.
9
A Figura 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» Modem «processor» PC «device» Impressora «device» Coluna SomFigura 8: Diagrama de instalação (de tipos) do Exemplo 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 9 ilustra uma possível configuração
(instanciação) desenhada a partir do diagrama da Figura 8.
sTelepac :ISP :Modem (Zoom 56K) meuPC:PC (PC XPTO, PIII 450MHz) Windows 2000 Office 97 Netscape :Monitor (ICL-5550) :Impressora (HP LJ1100)
5 Exercícios
Ex.1. Pretende-se o diagrama de componentes correspondente ao programa ex- pipes 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.net/ 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 (arquivos) 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 Telefonica conforme introduzido no Exemplo 3. Modifique o exemplo dado tendo em consideração que o serviço é acedido através de um cliente/browser Web.
Uniban – Sistemas de Informação
Ex.5. Pretende-se o diagrama de instalação para modelar a seguinte situação:
11
“Uma empresa industrial está estruturada em quatro departamentos: produção, comercial, controlo da qualidade, e administrativo-financeiro. Cada um destes departamentos tem um diretor respectivo. O diretor-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.