Capítulo 8 - UML MODELAÇÃO DA ARQUITECTURA

Transcrição

1 Capítulo 8 - UML MODELAÇÃ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 arquitectura 1 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.

2 2 CENTRO ATLÂNTICO - COLECÇÃO TECNOLOGIAS 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 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. (tipo de) componente Calculator c:calculator Instância 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

3 UML, PROCESSOS E FERRAMENTAS 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. wordprocessor.exe wordprocessor.exe dependência ISpell «interface» ISpell spell() wordsmith.dll realização (forma simples) interface wordsmith.dll 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 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.

4 4 CENTRO ATLÂNTICO - COLECÇÃO TECNOLOGIAS 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) 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.

5 UML, PROCESSOS E FERRAMENTAS 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 6 CENTRO ATLÂNTICO - COLECÇÃO TECNOLOGIAS 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.

7 UML, PROCESSOS E FERRAMENTAS 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» cor.hlp «library» pblib.dll «table» entrada.db «document» cor.ini «executable» wincor.exe {versão=3.2} «table» saida.db «library» sde32.dll «library» 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.

8 8 CENTRO ATLÂNTICO - COLECÇÃO TECNOLOGIAS 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 MS- Windows. (Nota: existe também este serviço na versão Web em servidor:Servidor Directório de Telefones :PC * Programa de Pesquisa Resultados 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.

9 UML, PROCESSOS E FERRAMENTAS 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 «processor» PC «device» Impressora «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) :Modem (Zoom 56K) meupc:pc (PC XPTO, PIII 450MHz) Windows 2000 :Impressora (HP LJ1100) Office 97 Netscape Figura 8.9: Diagrama de instalação (de instâncias) do Exemplo 8.4.

10 10 CENTRO ATLÂNTICO - COLECÇÃO TECNOLOGIAS 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 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) (ii) Considere apenas os nós existentes e os seus tipos de comunicação. 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.

11 UML, PROCESSOS E FERRAMENTAS 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.