• Nenhum resultado encontrado

3.2.diagramadecomponentes-exemploseexercicios

N/A
N/A
Protected

Academic year: 2021

Share "3.2.diagramadecomponentes-exemploseexercicios"

Copied!
11
0
0

Texto

(1)

UML – M

ODELAGEM DA

A

RQUITETURA

Tópicos Introdução Componentes e Nós Diagramas de Componentes Diagramas de Instalação Exercícios

1 Introdução

Diagramas de arquitetura1

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

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

Figura 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

(3)

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.

(4)

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.

(5)

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 Telefones

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

(6)

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

(7)

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.

(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 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”.

(9)

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 Som

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

(10)

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.

(11)

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.

Referências

Documentos relacionados

In this work, improved curves are the head versus flow curves predicted based on the correlations presented in Table 2 and improved by a shut-off head prediction

Também mostramos que a acusação de crimes contra a humanidade foi, ao nosso entendimento, a grande motivação para que Speer escrevesse sobre sua trajetória, em

Destarte, analisando o conceito de direito à intimidade, constata-se claramente que os dados genéticos, como informações diretamente relacionadas ao ser humano, são

Não apresentarei o argumento neste trabalho, pois importa dizer sobre a solução ter vindo, então, ao deixar de lado as recomendações de escrita de roteiro que eu seguira

Para que o estudo seja possível, houve um levantamento bibliográfico sobre o cenário do sistema produtivo da saúde no Brasil, tendo em vista a proteção

Nesse sentido, acredita-se que se atingiram os objetivos propostos na presente pesquisa, pois além de coletar dados e analisá-los, buscou-se efetuar uma ação social ao

Dando continuidade ao que estabelece o artigo já citado, o 2º artigo faz menção ao Manual de Boas Práticas de Atenção ao Parto e o Nascimento da